The best way is to wait them out in a vertical position, not the horizontal.
Yep, that's the best solution.
Quote:
One more thing, I totally appreciate that I can continue to play the game when the timer runs out, just no time bonus. Timer is a killer in any game, especially if it is a game over timer.
In general, time is a very delicate matter, but I wouldn't go that far: it depends on the game and on the role that time has. In my games I use time in different ways (or don't use it all). In this case, I thought that the time shouldn't stop progress - and I'm happy to get your approval!
By the way, speaking on time and points, here's an excerpt from the TIPS section of the manual: Quote:
Given that the time left at the end of an arena awards points, it is best to pick up the TIME bonus as late as possible. The absolute best is when fighting against the Ikuwor; however, since doing that might be very difficult due to the speed of the Ikuwor (and the same goes for the Hodwor), it is a good compromise to do it just before or after killing the last wor before the Hodwor. When there are a TIME bonus and one or more keys, an optimal strategy is: pick up all but the key closest to the TIME bonus; kill all the wors (Hodwor and Ikuwor included); pick up the TIME bonus; pick up the key.
RETREAM - retro dreams for Amiga, Commodore 64 and PC
levellord wrote:Lol, I hate those 2 flying nasties at the end of each level, so hard to shot!
Tip (for everyone, of course!): before killing the last "normal" enemy, locate a place that can be reached easily and that offers protection from at least two sides, and then move there and wait for the baddies - you'll be able to kill them even with just a single shot (and gain extra points)!
@all
Glad to see you're having fun! Keep at it and you'll soon break the 5-digits barrier ;)
RETREAM - retro dreams for Amiga, Commodore 64 and PC
Thanks for creating such a great game and also for spreading the word about the contest!
My pleasure!
@levellord
Quote:
Really good game: great gameplay, awesome GFX's, I enjoyed it more than I expected.
Glad to hear this :) Thanks.
Quote:
And with the AIA, it's playable with joystick (game did not recognize my joystick)!
Maybe I know why: for some reason, some controllers are reported and handled by SDL as analogue (even if they do have digital controls); Blastaway (and the same goes for BOH, Huenison and KOG, which all share the same code) asks for digital controls and thus gets "no device" as an answer.
RETREAM - retro dreams for Amiga, Commodore 64 and PC
Thanks for choosing Blastaway! I have shared the news on Twitter. I wish the initiative lots of success (I can't afford to participate to compos, though ).
@participants
Have fun!
RETREAM - retro dreams for Amiga, Commodore 64 and PC
Thanks for mentioning my games! BOH and Huenison might be particularly suitable as they already have their own online standings: BOH standingsHuenison hiscores.
@328gts
Thanks also for telling me about this thread :) Just one little note for the sake of precision: SkillGrid was not developed on AmigaOS 4, but on AmigaOS 3 ;)
RETREAM - retro dreams for Amiga, Commodore 64 and PC
Quite some progress has been done. This video shows a little bit of all that happened since the previous one:
Also, the game now has a page of its own on itch.io, where it's possible to follow the progress and download previews: https://retream.itch.io/quod-init-exit-iio (the currently available preview is quite old, but I plan to release a new one soonish).
RETREAM - retro dreams for Amiga, Commodore 64 and PC
I totally forgot I had told you about QUOD INIT EXIT! Well, over time there have been quite a number of changes about its sequels - quick recap: * I just released an updated version of QUOD INIT EXIT IIm; * I resumed the work on QUOD INIT EXIT IIo (recent-ish preview).
SkillGrid v1.3 is out! This short video shows the new weapon: https://www.youtube.com/watch?v=Umw_pzdYJkk Moreover, in addition to the other various improvements, I have given Amiga CD³² users the possibility to enable the hiscore loading/saving from/to NVRAM (I haven't received any feedback relatively to that, so the feature is completely experimental - see readme.txt on the CD).
v1.3 (21.05.2022) 1. Added the BEAM/ULTRA cell (shoots a big beam that is equivalent to 5 beams). 2. Moved the lateral beams of the triple beam one pixel down (to match the shape of the ultra beam). 3. Reduced by 16.7% the occurrences of the DAMAGE cell. 4. Worked on the music playback: · optimized the decoding; · optimized the handling of the state; · removed the pairing of channels on the same side (which caused the title and game over screens music to play louder than the in-game music - an originally intended effect which I have changed my mind about - and did not really work for channel 3 as that channel cannot sustain 28836.5 Hz). 5. Slightly improved the standard music quality by re-downsampling the data after improving the amplification. 6. Changed the keyboard handling so that it executes from a level 3 interrupt handler instead of a level 2 interrupt handler, in order to work around issues/lockups caused by expansion hardware sending INT2 interrupt requests. 7. Replaced [SPACE] with [LEFT ALT] and [RIGHT ALT] as [FIRE] button. 8. Made the startup procedure more robust (especially against audio playback performed with direct hardware access by other programs concurrently). 9. Made various little optimizations. 10. Added the possibility of enabling the loading/saving of the hiscore from/to the NVRAM in the Amiga CD³² bootable version - EXPERIMENTAL FEATURE: CHECK OUT THE README ON THE CD FIRST! 11. Worked on cells graphics: · fixed colors of beams on BEAM/DOUBLE and BEAM/TRIPLE cells; · fixed a pixel on the border of the ASTEROIDS, BEAM/DOUBLE and BEAM/TRIPLE cells. 12. Worked on manual and stragegy guide: · renamed DOUBLE BEAM and TRIPLE BEAM as BEAMS/DOUBLE and BEAMS/TRIPLE, respectively; · added the information for the BEAMS/ULTRA cell; · adapted the information for the other BEAMS/* cells; · added the BEAMS paragraph; · updated the ASTEROIDS, BEAM/DOUBLE and BEAM/TRIPLE cells images; · updated the CONTROLS table; · fixed the outer antialiasing of the BEAM/TRIPLE, BOOST and BRAKE cells images; · fixed the kerning of the last character of the italic strings. 13. Set the default tool of the manual and strategy guide icons to "Apdf". 14. Updated the artwork to reflect the new beams graphics.
RETREAM - retro dreams for Amiga, Commodore 64 and PC
Somebody on itch.io reported that SkillGrid hangs on his/her A4000 (with 68060), but provided no details. Luckily, one of my friends/testers has an A4000 equipped with a 68060 and managed to reproduce the problem (if not exactly the same, I hope a strictly related one). What he found out is that if he had Roadshow running, the game would hang in the title screen shortly after starting up. Given that SkillGrid takes over the system entirely, the first thing that came to mind was that his network board (an X-Surf-100), after being activated/used by RoadShow before the startup of the game, was triggering an INT2 interrupt and keeping on doing so continuously as it was not getting an ack due to the fact that my level 2 interrupt handler, which only cares about the keyboard, simply cleared the INTREQ.PORTS bit and returned. I searched for information about the X-Surf-100 on the net and I got confirmation that it uses the INT2 line (and seemingly also the INT6 one, but that is not relevant to SkillGrid as it has the level 6 interrupt disabled). I provided him with a version of the game with the level 2 interrupt disabled and it turned out to work just fine, even with RoadShow running at startup. Therefore, I have now prepared a new version (1.3) which handles the keyboard through the level 3 interrupt and which is thus immune to any expansion hardware (except for hardware that continuously triggers NMIs, that is).
Doing this work got me started once again, and so I also made some other improvements - you can find the details in the changelog at the bottom of this post, but here's the most important one:
For who is not familiar with the game: the addition is the BEAM/ULTRA cell, which makes the spaceship weapon exceptionally powerful (getting rid of the bosses with it is extra easy).
I seized the occasion to also add this little paragraph to the manual which clarifies how beams work (it has been so since day 1, but it had never been explained):
The new version is practically ready, but before releasing it I'd really really really like to get the Amiga CD32 NVRAM issue fixed! In fact, hiscore loading/saving is still disabled for the version that boots on Amiga CD32 directly from CD. Unfortunately, having no such machine, I can't test my code, so I need help. More precisely, I need someone with an Amiga CD32 equipped with an HD/CF/SD to run this test suite and report the result (it's all very simple - basically: download the archive, unpack it on the drive, run the script from shell, follow the on-screen instructions and report the result). Thanks in advance to the good souls who will help!
Changelog
v1.3 (unreleased) 1. Added the BEAM/ULTRA cell (shoots a big beam that is equivalent to 5 beams). 2. Moved lateral beams of the triple beam one pixel down (to match the shape of the ultra beam). 3. Reduced by 16.7% the occurrences of the DAMAGE cell. 4. Worked on the music playback: optimized the decoding; optimized the handling of the state; removed the pairing of channels on the same side (which caused the title and game over screens music to play louder than the in-game music - an originally intended effect which I have changed my mind about - and did not really work for channel 3 as that channel cannot sustain 28836.5 Hz). 5. Changed the keyboard handling so that it executes from a level 3 interrupt handler instead of a level 2 interrupt handler, in order to work around issues/lockups caused by expansion hardware sending INT2 interrupt requests. 6. Replaced [SPACE] with [LEFT ALT] and [RIGHT ALT] keys as [FIRE] button. 7. Made the startup procedure more robust (especially against audio playback performed with direct hardware access by other programs concurrently). 8. Made various little optimizations. 9. Worked on cells graphics: fixed colors of beams on BEAM/DOUBLE and BEAM/TRIPLE cells; fixed a pixel on the border of the ASTEROIDS, BEAM/DOUBLE and BEAM/TRIPLE cells. 10. Worked on manual and stragegy guide: renamed DOUBLE BEAM and TRIPLE BEAM as BEAMS/DOUBLE and BEAMS/TRIPLE, respectively; added the information for the BEAMS/ULTRA cell; adapted the information for the other BEAMS/* cells; added the BEAMS paragraph; updated the ASTEROIDS, BEAM/DOUBLE and BEAM/TRIPLE cells images; updated the controls table; fixed the outer antialiasing of the BEAM/TRIPLE, BOOST and BRAKE cells images; fixed the kerning of the last character of the italic strings. 11. Set default tool of manual and strategy guide icons to "Apdf". 12. Updated artwork to reflect the new beams graphics.
RETREAM - retro dreams for Amiga, Commodore 64 and PC
Once again, working on other projects inspired improvements for the little custom framework used by MeMO. I have just rebuilt and re-released the game. You can download it from the usual place: https://www.retream.com/MeMO Should you experience any problem, please let me know.
v3.17 (02.05.2022) * Built against latest custom framework (which features a more robust startup code and a few little optimizations).
RETREAM - retro dreams for Amiga, Commodore 64 and PC
This update was not planned, but, still, it happened - and makes the demo even better. In short: it improves the music, it improves the audio-to-video sychronization, it adds a few more palette effects and brings other little improvements (for the details, check out the changelog below).
v1.4 (29.04.2022) * Improved music: improved S/N ratio by eliminating a peak (caused by the "str" of "street" in the spoken part) and re-normalizing the waveform; amplified initial part a little bit; reduced greatly the noise that affected the coda (due to the 8-bit quantization) by amplifying that part of the waveform to the maximum and balancing that with a real-time volume change; increased sampling frequency to 29073 Hz (side effects: channels 2 and 3 can no longer be used, so the output volume is lower; music decoding takes a little longer as there is more data to decode each frame; the CHIP bus time taken by audio DMA is almost halved, which makes the demo less demanding). * Added switch-off of filter to ensure music sounds as it is supposed to. * Fixed audio-to-video synchronization: fixed drifting caused by the difference between the actual and theoretical rates (~49.92 VS 50 Hz) of the video refresh (that, by the end of the demo, caused an asynchronism of ~0.5 s); fixed 60 ms asynchronism caused by the fact that the first three frames required for music setup/buffering were ignored; fixed a few timing marks in the script (an off-by-one mark which caused a peak of operations in the specified frame; a mark that caused the following effect to execute 4 frames too late; a few marks that were off by a frame). * Fixed a bad routine pointer (caused by a wrong letter in a label in the source code; it is quite incredible that this did not produce disastrous results). * Added some palette effects. * Optimized music decoding by unpacking and undeltaing data at the same time (why it was not like this right from the beginning is a mistery). * Made some other small optimizations. * Made startup and cleanup code more robust by shielding some critical operations from NMIs and by dealing with audio playback performed with direct hardware access by other programs concurrently. * Added version string. * Improved/extended README.
Edited by saimo on 2022/4/30 11:18:21 Edited by saimo on 2022/5/1 10:15:53
RETREAM - retro dreams for Amiga, Commodore 64 and PC
SkillGrid v1.2 is out! This version improves the game further and, above all, brings also the PRESS PLAY ON TAPE edition, a special version whose soundtrack is the rockin' tongue-in-cheek song "Man with the Gun" by the Commodore 64 revival band PRESS PLAY ON TAPE!
Like all the RETREAM games, SkillGrid is 100% free. However, who likes it is kindly asked to offer some support to somebody who is a victim of any kind of violence.
CHANGELOG
v1.2 (11.04.2022) 1. Added the PRESS PLAY ON TAPE edition. 2. Made the BOOST cell increase the scrolling speed by just 50% (instead of 100%). 3. Fixed the chasing of the spaceship (due to a bhi in place of a bhs, downwards missiles would chase the spaceship as a consequence of catching the CHASE cell). 4. Improved the "escapes critical" speech warning. 5. Replaced the title screen writings. 6. Worked on the manual: improved/fixed/extended the setup/launch instructions; added information relative to the PRESS PLAY ON TAPE edition. 7. Moved history to separate file. 8. Updated/improved installer. 9. Moved 'S' and 'G' one pixel down and inverted pixels at the bottom of 'r' in the small logo in the bonus directory icon for perfect baseline alignment. 10. Added drawer icon where applicable (the real reason is to ensure that the drawers are shown as intended when browsing the CD from Workbench; however, it can be used also as the icon of the drawer the game is installed in - the installer now even asks if the user wants it; this icon had been omitted until now because it is impossible to provide an icon that suits the styles of all the iconsets available for AmigaOS). 11. Improved the icons layout on the CD.
@saimoI have just released SkillGrid v1.1beta! Like all the RETREAM games, SkillGrid can be downloaded freely, with the kind request of offering some help to the victims of Putin's attack to Ukraine.
This version enhances the game greatly, as documented by the huge changelog below. It has been held back for a long time by a problem of the bootable version for the Amiga CD³² (which is why it is still a beta). The owners of such machine can help. For details, please see the readme file in the package.
v1.1beta (12.03.2022) 1. Fixed the asteroids activation (they could activate also after a reset of their timer, e.g. when they were postponed and, in the meanwhile, a milestone was reached). 2. Fixed the milestone handling (it replenished the shield and the charge in those extremely rare occasions when the ship had just been destroyed, preventing the game over to execute). 3. Fixed the assignment of points when the MUSIC MODE cell was caught while the Boltspitter was active (25 instead of 5 points were awarded). 4. Fixed the audio decompression routine (due to forgetfulness, 1 byte was not changed in one of the two routines involved; that caused noise during playback, but "luckily" the effects with SkillGrid's own music were not audible; in fact, the bug was discovered when the PRESS PLAY ON TAPE edition was made; also, due to INTREQ.AUD0 being used for multiple purposes, the very last tiny chunk of one-shot music was not played). 5. Fixed the dynamic selection of audio channels (under some rare circumstances, it could steal a channel from music). 6. Fixed the rendering of the halt sign (it processed 18 lines instead of 6). 7. Fixed a data file (it contained about 3 kB of useless data). 8. Fixed the (potential) malfunctioning caused by hiscore saving when the game booted from CD on an Amiga CD³² configured to have nonvolatile.library save data on a device other than NVRAM (i.e. when there is a volume that has Prefs/Env-Archive/Sys/nv_location defined). See also the notes below about hiscore saving. 9. Fixed/improved/updated the manual (in particular: in one place it erroneously said that the scrolling speed is halved when the Skull activates, which is false; it failed to mention that the TURN cells award 25 points in music mode). 10. Changed the BRAKE cell type from bonus to undefined (as it has a negative effect when time is running out, given that it delays the appearance of cells, and thus also of the TIME cell); graphically, now the cell has a yellow border. 11. Changed the BOOST cell type from malus to undefined (as it has a positive effect when time is running out, given that it accelerates the appearance of cells, and thus also of the TIME cell); graphically, now the cell has a cyan border. 12. Replaced the 30 seconds grace period at the beginning of a game with progressive introduction of the various cells types (this makes for a gentler introduction for beginners and allows to improve/maximize the spaceship power and thus be ready for what will follow). 13. Added the TRIPLE BEAM cell. 14. Changed the look of caught cells so that they appear disabled (instead of flat-filled). 15. Tweaked the transparency of cells when asteroids, Mothership, Skull and music mode are active to preserve their double-color look even if painted in a single color. 16. Fixed one pixel of the POINTS BONUS cell. 17. Made background layer more vivid (but still not obtrusive). 18. Changed flash color when the Boltspitter activates from green ($00ff00) to orange ($ff8000). 19. Improved the sprites: modified the palette to make sprites more vibrant and distinguishable; added 8 new UFO sprites; reworked spaceship, Boltspitter, Morthership and Skull graphics; reworked game start, pause and game over writings/icons. 20. Improved the music: changed a few volumes for a better mix; compressed the bass instrument a little bit; increased the S/N ratio by means of the changes above and by reducing some peaks (without causing any distortion); lowered by an octave the bass instrument in the "danger" tune; improved the compression algorithm for a better compression ratio; made the decompression routine faster; assigned to the Boltspitter the same tune of the other bosses; assigned the "danger" tune (previously assigned to the Boltspitter) to asteroids and missiles. 21. Improved the sound samples: removed clicks from a few of them; shortened a few of them; reworked the explosion sound; added the "charge low" speech warning. 22. Added cycling writings (including hiscore) to the title screen. 23. Touched up the graphics of 'M' and 'W' everywhere. 24. Improved the controls: replaced [REWIND] with [FIRE2]/[BLUE] so that also a normal 2-button joystick can be used; added support for [FIRE2] also to the installable version (which is crucial for running it on Amiga CD³² consoles that do not have a keyboard); added keyboard support (i.e. now the cursor keys act as joystick directions and [SPACE] as [FIRE1]). 25. Improved file loading so that, when the game is not running from floppies, the SkillGrid?: assigns and the launcher script are no longer needed. 26. Trashed AmigaOS on the Amiga CD³² to gain the RAM necessary to run the game (which requires more RAM than before, and unfortunately at boot the Amiga CD³² kernel steals quite a lot of RAM); as a consequence: removed the possibility of quitting to AmigaOS; hiscores are saved exclusively to NVRAM (i.e. Prefs/Env-Archive/Sys/nv_location is ignored); implemented direct EEPROM access routines to save the hiscore to NVRAM (still, the NVRAM slot is allocated legally and nothing is touched outside of it; as a positive side effect, saving is now much faster). [This feature is disabled - see the beta release notice.] 27. Improved hiscore saving: restricted it to just when a new hiscore is made; reduced by 6 bytes the occupation in the Amiga CD³² (tiny) NVRAM. 28. Worked on the CD ISO image: minimized buffers (to gain RAM); laid out files/directories in a manner that will hopefully make the loading faster on the Amiga CD³²; added readme.txt to the root directory; added printable package artwork and documentation. 29. Made the startup and cleanup code more robust and more likely to succeed in low CHIP RAM situations. 30. Made various speed and memory optimizations. 31. Adapted the game to 3 floppies (unfortunately, due to the additional data, it cannot fit in 2 floppies anymore). 32. Added a strategy guide. 33. Improved the readme.txt files. 34. Worked on icons: added icons to all the user-relevant files/directories; redrawn / touched up the icons; made all icons 72 pixels tall; removed paths from the default tools where appropriate. 35. Updated/improved the installer. 36. Removed the "wd" bits from the files on floppies. 37. Reworked the package artwork.
I guess you've been influenced by the video examples, but "native" chunky would be better used for other things (although, I did try to imagine if an interesting horizontal shooter could be done). To be honest, I feared I'd get a flock of Doom-like game requests/proposals :D
As of today, all the RETREAM games are available for free download at https://www.retream.com / https://retream.itch.io. The store will not ask for any payment and it will not even be possible to make a donation to RETREAM. However, given the sad events that these days are devastating Ukraine (and the world), it would be nice if who downloads and likes the games also makes a donation (of any kind, in any way) for Ukraine. Enjoy!
I don't know how that works, so I can't answer. The best, most complete and shortest explanation I can give is the one in the CORE IDEA section of the documentation.
PED81C is a video system for AGA Amigas that provides pseudo-native chunky screens, i.e. screens where each byte in CHIP RAM corresponds to a dot on the display. In short, it offers chunky screens without chunky-to-planar conversion or any CPU/Blitter/Copper sweat.
Notes: * due to the nature of the system, the videos must be watched in their original size (1920x1080); * YouTube's video processing has slightly reduced the visual quality (i.e. the result is better on real machines).
Full details straight from the documentation:
--------------------------------------------------------------------------------
CORE IDEA
The core idea is using SHRES pixels ("pixels" from now on) to simulate dots in a
CRT/LCD-like fashion.
Each dot is made of 4 pixels as follows:
ABCD
ABCD
ABCD
ABCD
where
X
X
X
X
represents a pixel.
The eye cannot really distinguish the pixels and, instead, perceives them almost
as a single dot whose color is given by the mix of the colors of the pixels. The
pixels thus constitute the color elements ("elements" from now on) of the dot.
The effect is not perfect though, as the pixels can still more or less be seen.
The sharper the display / the bigger the pixels, the worse the visual mix. In
practice, though, the effect works acceptably well on CRT, LCD and LED displays
alike.
The pixels can be assigned any RGB values ("base colors" from now on).
For example, the most obvious choice is:
RGBW
RGBW
RGBW
RGBW
Starting from the left, the pixels are used for the red, green, blue and white
elements of dots. The pixels can be assigned any values in these ranges:
R: $rr0000, where $rr in [$00, $ff]
G: $00gg00, where $gg in [$00, $ff]
B: $0000bb, where $bb in [$00, $ff]
W: $wwwwww, where $ww in [$00, $ff]
As a consequence, there is an overall brightness loss of at least 50%. For
example, the white dot (the brighest one) is obtained by assigning the pixels
the maximum values in the ranges (i.e. R = $ff0000, G = $00ff00, B = $0000ff,
W = $ffffff), which add up to $ffffff*2, the half of the absolute maximum value
of the 4 pixels, i.e. $ffffff*4.
Each set of base colors ("color model" from now on) produces the specific
palette that the dots are perceived in ("dots palette" from now on). To
understand how to calculate the dots palette, it is first necesssary to look at
how the screens work.
The raster, i.e. the matrix of the bytes (stored as a linear buffer) that
represent the dots, must reside in CHIP RAM. It is used as bitplane 1 and also
as bitplane 2, shifted 4 pixels to the right.
This how a byte %76543210 (where each digit represents at bit) in the raster is
displayed:
bitplane 2: 76543210
bitplane 1: 76543210
****
The marked bits are those that produce the dot that corresponds to the byte:
ABCD
ABCD
ABCD
ABCD
^^^^
bitplane 2: 76543210
bitplane 1: 76543210
The elements are thus indicated by the bit pairs in the byte:
%73 -> element A
%62 -> element B
%51 -> element C
%40 -> element D
Replacing the digits with letters gives a better representation:
%ABCDabcd
where:
X = most significant bit for element X
x = least significant bit for element X
Each element can have only 4 values corresponding to the bit pairs %00, %01,
%10 and %11. Such values are those stored in COLORxx. Therefore, the bit pairs
represent the COLORxx indexes:
bitplane 4 and 3 = %00 -> element A -> COLOR00 thru COLOR03
bitplane 4 and 3 = %01 -> element B -> COLOR04 thru COLOR07
bitplane 4 and 3 = %10 -> element C -> COLOR08 thru COLOR11
bitplane 4 and 3 = %11 -> element D -> COLOR12 thru COLOR15
Given that there are 4 elements and that each element can have 4 different
values, the total number of combinations (i.e. of dots colors) is 4^4 = 256.
In the RGBW color model, COLORxx could be set up as follows (for simplicity, the
low-order 12 bits are left to the automatic copy performed by AGA):
Without CPU and/or Blitter intervention, those bits cannot be eliminated - but
processing data is precisely what PED81C tries to avoid, so it is necessary to
find a way to deal with the spurious bits.
This is what happens with two consecutive bytes %ABCDabcd and %EFGHefgh:
Between the dots produced by the bytes as explained above ("desired dots" from
now on) is a dot that is made of bits coming from both the bytes ("middle dot"
from now on), i.e. %EFGH and %abcd. The simplest solution would be masking the
middle dot out with a no-DMA vertically repeating jailbar mask sprite, but that
would introduce a horrible vertical spacing between the columns of dots and
reduce further the brightness of the screen.
A smarter solution would be adding one more selector bitplane to distinguish
between desired dots and middle dots (for readability, from now on, 0 bits are
replaced with '·' where needed):
COLOR16 thru COLOR31 could then be set up so that the middle dots are mixes of
the desired dots, keeping in mind that the middle dots have the most and least
significant bits swapped around (the least significant bits of the left dot end
up in the most significant bits of the middle dot and the most significant bits
of the right dot end up in the least significant bits of the middle dot). The
simplest settings reflect the settings of the desired dots, but with the RGB
values assigned to the %01 and %10 bit pairs swapped around.
For example, in the RGBW color model:
left dot: $550000
middle dot: $ff0000
right dot: $aa0000
The middle dot would end up being a full red, stronger than the desired dots,
which is not visually correct nor logical, as the middle dots would be more
prominent than the desired dots. A solution could be dimming the RGB values of
middle dots.
For example, if they were halved, the result would be:
left dot: $550000
middle dot: $800000
right dot: $aa0000
The middle dot would be a good average of the desired dots. That works
conceptually, but in practice it causes the middle dots columns to look like
vertical scanlines - which is not desirable either.
The case of different hues is even more complicated. For example, if the bytes
were %10001000 ($ff0000) and %010001000 ($00ff00), the result would be:
left dot: $ff0000
middle dot: $55aa00
right dot: $00ff00
The middle dot would be a kind of average of the actual dots, although not
really good (a good average would be $808000).
It is possible to experiment with the COLORxx values to achieve different
results, but the overall scanlines-like effect would still remain. Moreover, the
3rd selector bitplane would steal a lot of CHIP bus slots. An alternative is
required.
The proposed solution consists in eliminating the 3rd selector bitplane and
assigning the bit pairs %01 and %10 the same RGB values (which basically gives
the most and least significant bits the same weight). As a downside, this
reduces the amount of dots colors: given that each element can have only 3
different values, the total number of colors falls down to 3^4 = 81.
left dot: $880000
middle dot: $ff0000
right dot: $880000
Again the middle dot would be brighter than the actual dots, but now this can
be easily solved by simply forbidding the %01 bit pair in bytes, given that it
can always be replaced by the %10 bit pair. So, the bytes would instead be both
%10000000 ($880000) and the result would be:
left dot: $880000
middle dot: $880000
right dot: $880000
Also the case of different hues, %10001000 ($ff0000) and %01000100 ($00ff00),
gives a correct result (for complete correctness, in this example the low-order
bits of COLOR02 and COLOR05 are set to 0):
left dot: $ff0000
middle dot: $808000
right dot: $00ff00
--------------------------------------------------------------------------------
COLOR MODELS
The CORE IDEA section introduces the RGBW color model, but the number of
possible color models is huge (2^288). For best results, it is adviceable to
define the color models that are most suitable to the graphics to be displayed.
The most obvious general-purpose color models are:
* CMYW: Cyan Magenta Yellow White
* G: Greyscale
* KC: Key Colors (red yellow green cyan blue magenta white)
* RGBW: Red Green Blue White
This table shows the COLORxx settings for the general-purpose color models.
For the G color model, the arithmetically perfect assignment would be:
* COLOR01, COLOR02: $333333
* COLOR05, COLOR06: $666666
* COLOR09, COLOR10: $999999
* COLOR13, COLOR14: $cccccc
However, the resulting dots palette would contain only 26 unique colors.
Each color model has strenghts and weaknesses. This table provides an evaluation
of the general-purpose color models (COLORS = number of unique colors in the
resulting dots palette).
Once the color model is defined, the corresponding dots palette can be
calculated by mixing the RGB values assigned to the bit pairs in the bytes from
0 to 255. The bytes which include a %01 bit pair should be treated as illegal
and thus be assigned one of the RGB values also assigned to a legal byte (the
easiest solution is to use the value of byte 0). The calculation of the RGB
value ($6a2b40) corresponding to the byte %10011010 in the RGBW color model,
done in the CORE IDEA section, makes for a practical example.
The PED81C archive includes GeneratePalette, a handy tool that generates a dots
palette according to the desired color model and then saves it to an ILBM file.
It normalizes to $ff the components of the calculated colors, so that the latter
are brighter and have a higher dynamic range than the actual dots palette
colors, allowing for better graphics conversion. Also, it assigns the value of
byte 0 to the illegal bytes.
X0: 24-bit RGB value for the %00 pair of element X
X2: 24-bit RGB value for the %10 pair of element X
X3: 24-bit RGB value for the %11 pair of element X
FFIS100: $ff treated internally as $100 (for better rounding)
FILE: output file
The 24-bit RGB values must be in hexadecimal format without prefix.
The palettes are suitable for screens which use bitplanes 3 and 4 as selector
bitplanes.
The PED81C archive also includes:
* the palettes for the general-purpose color models, stored as ILBM pictures;
* GeneratePalettes, a script that generates a few palettes (it can be used also
as a reference for GeneratePalette usage).
The palettes can be used to draw/convert graphics.
For example, to display a picture in an RGBW screen:
1. draw/remap the picture with the RGBW palette;
2. save the picture as raw chunky data;
3. copy the raw chunky data to the raster or use it directly as the raster.
--------------------------------------------------------------------------------
SETTING UP AND USING SCREENS
PED81C screens are obtained by opening SHRES screens with these peculiarities:
* the raster must be used as bitplane 1 and 2;
* bitplane 3 must be filled with %01010101 ($55);
* bitplane 4 must be filled with %00110011 ($33);
* bitplanes 2 and 4 must be shifted horizontally by 4 pixels;
* COLORxx must be set according to the chosen color model;
* the 4 pixels in the leftmost column are made of just the least significant
bits of the leftmost dots, so it is generally recommendable to hide them by
moving the left side of the window area by 1 LORES pixel to the right.
Notes:
* to obtain a screen which is W LORES pixels wide, the width of the raster must
be W*4 SHRES pixels = W/2 bytes (e.g. 320 LORES pixels -> 1280 SHRES pixels =
160 bytes = 160 dots);
* to obtain a scrollable screen, allocate a raster bigger than the visible area
and, in case of horizontal scrolling, set BPLxMOD to the amount of non-
fetched dots (e.g. for a raster which is 256 dots wide and is displayed in
a 320 LORES pixels area, BPLxMOD must be 256-320/2 = 96);
* HIRES/SHRES resolution scrolling is possible, but it alters the colors of the
leftmost dots;
* given the high CHIP bus load caused by the bitplanes fetch, it is best to
enable the 64-bit fetch mode (FMODE.BPLx = 3).
In general, given a raster which is RASTERWIDTH dots wide and RASTERHEIGHT dots
tall, the values to write to the chipset registers in order to create a centered
screen can be calculated as follows:
* SCREENWIDTH = RASTERWIDTH * 8
* SCREENHEIGHT = RASTERHEIGHT
* DIWSTRTX = $81 + (160 - SCREENWIDTH / 8)
* DIWSTRTY = $2c + (128 - SCREENHEIGHT / 2)
* DIWSTRT = ((DIWSTRTY & $ff) << 8) | ((DIWSTRTX + 1) & $ff)
* DIWSTOPX = DIWSTRTX + SCREENWIDTH / 4
* DIWSTOPY = DIWSTRTY + SCREENHEIGHT
* DIWSTOP = ((DIWSTOPY & $ff) << 8) | (DIWSTOPX & $ff)
* DIWHIGH = ((DIWSTOPX & $100) << 5) | (DIWSTOPY & $700) |
((DIWSTRTX & $100) >> 3) | (DIWSTRTY >> 8)
* DDFSTRT = (DIWSTRTX - 17) / 2
* DDFSTOP = DDFSTRT+SCREENWIDTH / 8 - 8
Example registers settings for:
* screen equivalent to a 319x256 LORES screen
* 160 dots wide raster
* blanked border
* 64-bit sprites and bitplanes fetch mode
* sprites on top of bitplanes
* sprites colors assigned to COLOR16 thru COLOR31
The selector bitplanes need a lot of RAM. To save RAM drastically it is enough
to store just 1 line for each of them and to reset BPLxPTx with the Copper
during the horizontal blanking period of every rasterline. As a downside, this
steals some CHIP bus slots and complicates Copperlists.
#2
If a selector bitplane is omitted, the elements become 2 couples of identical
elements; if both the selector bitplanes are omitted, all the elements become
equal. Omitting the selector bitplanes saves (a lot of) CHIP bus slots and can
be useful in particular cases. For example, the demo THE CURE does not use any
selector bitplanes and uses bytes of the kind %HHHHLLLL, where H = High bit,
L = Low bit; this, thanks to jailbar mask sprites produces perfect LORES-looking
4-color pixels (which, together with bitplanes DMA toggling every other
rasterline, produces a dot-matrix display).
#3
If the visual output suffers from a heavy "jailbars" effect, it could be
improved by shifting every other rasterline by 1 to 3 pixels - for example:
To lessen the dithering of tweak #3 and improve the color mix, the shifting can
also be inverted on an alternate frame basis - for example, the rasterlines
could be shown on the next frame as follows:
However, this causes flickering visuals (especially on displays with quick
response), so it is not really recommendable.
#5
Adding a horizontal scanlines effect by swapping the elements palette on an
alternate line basis (through BPLCON4) makes the visual output resemble that of
a CRT display.
#6
To reduce the amount of graphics to draw and the memory usage, the raster size
can be halved by repeating each rasterline once (which is easily obtained by
means of FMODE.BSCAN2 and BPLxMOD). This combines well with tweak #5.
#7
If needed, the bitplanes order can be reversed, i.e. the selector bitplanes
could be assigned bitplanes 1 and 2, and the raster bitplanes could be assigned
bitplanes 3 and 4:
In this case, COLORxx need to be set up differently:
bitplane 2 and 1 = %00 -> element A -> COLOR00 COLOR04 COLOR08 COLOR12
bitplane 2 and 1 = %01 -> element B -> COLOR01 COLOR05 COLOR09 COLOR13
bitplane 2 and 1 = %10 -> element C -> COLOR02 COLOR06 COLOR10 COLOR14
bitplane 2 and 1 = %11 -> element D -> COLOR03 COLOR07 COLOR11 COLOR15
Note: GeneratePalette does not support such arrangement.
#8
With a careful setup of COLORxx, the unused 4 bitplanes can be used to overlay
other graphics or even up to two more chunky screens, optionally with colorkey
and translucency. That, however, would increase noticeably the CHIP bus load.
The meaning of PED81C is "Pixel Elements Dots, 81 Colors".
#2
Although due to the middle dots the logical horizontal resolution is half of the
physical one, the averaging provided by the middle dots and SHRES quite fool the
eye.
#3
Visually, the best results are obtained with complex/dithered images, as plain
color areas and geometrical shapes reveal the pixels and the middle dots. In
particular, isolated dots look 3x-ish wide.
#4
81 is only the theoretical maximum number of dots colors. The actual number
depends on the chosen base colors.
#5
The core idea could be used also to display 24-bit pictures, but the coarseness
of the method wastes completely the subtlety of such high color resolution (also
verified experimentally).
#6
Usage of PED81C is of course welcome and encouraged. It would be nice if credit
were given. If used in a commercial production, I would appreciate if permission
were asked first and if I could receive a little share of the profits.
PED81C is very CHIP bus intensive: the bitplanes data fetched are twice that of
an equivalent 256 colors LORES screen. If Lisa had been able to use the BPLxDAT
values of inactive bitplanes (like, for example, Denise does with bitplanes 5
and 6 when 4 bitplanes only and HAM are enabled) BPL3DAT and BPL4DAT could have
been loaded with the selector values thus halving the DMA fetches - but
unfortunately that is not the case.
Therefore, one might wonder whether is PED81C is actually advantageous. A lot
depends on how graphics are rendered: for example, a favourable case is when the
CPU can keep on executing cached code after writing to CHIP RAM so that no/few
cycles are wasted between writes. A general and indirect evaluation can be done
by comparing PED81C to the traditional C2P methods as follows.
The measurements, for simplicity, are based on the amount of data to render,
convert (if needed) and fetch for output relatively to 1 line.
Reference regular screen:
* 320 pixels wide LORES
* 6 bits deep screen (for fairness, because PED81C can at most output 81 unique
colors and the actual number of colors, as shown above, might be even less
depending on the color model)
Assumptions:
* 1 chunky pixel = 1 byte
* CPU and Blitter operations in CHIP RAM involve 6 bitplanes
In only CHIP RAM is available, the figures are as follows.
If FAST RAM is available, the figures of PED81C do not change (as the raster
always resides in CHIP RAM), while the figures of the other cases are as
follows.
CPU-only C2P:
* rendering in FAST RAM: 320 bytes
* C2P reads from FAST RAM: 320 bytes
* C2P writes to CHIP RAM: 240 bytes
* bitplanes fetch: 240 bytes
* total: 640 bytes FAST RAM, 480 bytes CHIP RAM
CPU+Blitter C2P, 1 CPU pass and 1 Blitter pass:
* rendering in FAST RAM: 320 bytes
* C2P reads by CPU from FAST RAM: 320 bytes
* C2P writes by CPU to CHIP RAM: 240 bytes
* C2P reads by Blitter from CHIP RAM: 240 bytes
* C2P writes by Blitter to CHIP RAM: 240 bytes
* bitplanes fetch: 240 bytes
* total: 640 bytes FAST RAM, 960 bytes CHIP RAM
Overall, PED81C has the edge performance-wise, especially considering that CPU
and Blitter are not busy with converting data. It must be pointed out, though,
that PED81C's logical horizontal resolution is halved (hence the 160 bytes per
line) and that the overall visual quality is inferior to that of a regular
screen mode.
The idea of using SHRES pixels as elements is by Fabio Bizzetti, who used it for
his Virtual Karting and Virtual Karting II games.
In the late 90s, I was in touch with him and he told me that his idea was to
"fool the RF signal" (or something along these lines). This got me thinking and
I came up with the core idea. Before writing here (in 2022!) I had never
bothered checking what he actually had done, but now I deemed it appropriate to
do it in order to provide a brief description of his method, both as an
acknowledgement of his brilliant idea and to provide more food for thought.
After starting Virtual Karting II in UAE, having a look at the moving graphics,
grabbing a screenshot, checking the values of BPLCON0 and BPLCON1, and checking
the bitplanes memory, I found out that he used bitplanes 1-3 as selector
bitplanes and assigned the pixels these elements (from left to right): red-
orange-yellow-green-cyan-azure-blue-purple (so, there are no middle dots and
dots are really 2x-wide). To mitigate the columns-looking result, he applied the
crosshatch tweak, swapping the scroll offsets on an alternate frame basis.
#2
Between the end of the 90s and 2003 I had created a system (implemented as a
shared library) based on the same core idea, but using 3 selector bitplanes.
PED81C is actually a simplification of that system, born from precisely from the
removal of the middle dots selector bitplane to improve the speed.
The old system was really rich feature-wise, as it provided:
* 256 colors screens
* HalfRes screens: screens like PED81C's
* FullRes screens: screens without middle dots - this was achieved by means of
a conversion performed by the CPU, optionally assisted by the Blitter (for
the record, the CPU-only conversion allowed 320x256 screens at about 50 fps
on an Amiga 1200 equipped with a Blizzard 1230-IV and 60 ns FAST RAM)
* chequer effect: crosshatch tweak for HalfRes screens
* double and triple buffering
* 5 embedded color models (RGBW, RGBM, RGBP, RGBPS, RGB332)
* color/palette handling functions (color setting, color remapping, 24-bit
fading and 24-bit cross-fading)
* Cross Playfield mode: 256 color screen overlay on top of another screen with
any degree of opacity between 0 and 256 (in practice, this produced 16-bit
graphics)
* Dual Cross Playfield mode: like Cross Playfield mode, but with a selectable
colorkey
* graphical contexts (clipping, drawing modes)
* pixmap fuctions (blitting, zooming, rotzooming)
* graphical primitives
* font functions
* ILBM functions
One might wonder why such system is not public - the reasons are:
* the core would need to be re-designed;
* the implementation could be better;
* the accessory functions (like the graphical ones) should be in a separate
library;
* the documentation would need a major overhaul.
Basically, I do not consider the system suitable for public distribution. I
would rather redo it from scratch... but that is precisely why PED81C was born:
while thinking how to improve the system, I realized how to eliminate the 3rd
selector bitplane and decided to get rid of the FullRes screens, because the
point of these systems is obtaining chunky screens without data conversion
(otherwise, it is better to use one of the traditional C2P methods, which give
better visual results).
#3
Originally I had planned to use PED81C to make a new game. However, I could not
come up with a satisfactory idea; moreover, due to personal reasons, I had to
stop software development. Given that I could not predict when/if I would able
to produce something with PED81C and given that the war in Ukraine put the world
in deep uncertainty, I decided that it was better to release PED81C to avoid
that it went wasted and also as a gift to the Amiga community.
I must admit I have been tempted to provide an implementation of PED81C in the
form of a library or of a collection of functions, but since setting up PED81C
screens is easy and since general-purpose routines would perform worse than
tailor-made ones, I decided to let programmers implement it in the way that fits
best their projects.
Edited by saimo on 2022/3/9 18:03:25 Edited by saimo on 2023/6/19 22:33:45 Edited by saimo on 2023/6/21 16:11:05 Edited by saimo on 2023/6/26 20:56:07 Edited by saimo on 2023/11/28 23:01:50 Edited by saimo on 2023/11/28 23:05:45 Edited by saimo on 2023/11/29 12:13:25 Edited by saimo on 2024/4/2 21:12:09
RETREAM - retro dreams for Amiga, Commodore 64 and PC
Want to have a look at SkillGrid v1.1? Here's a huge rollercoaster longplay for you to enjoy! The video is quite long, but if, you go through it all, you'll get a perfect idea of how varied and dynamic the gameplay is. (By the way, I did catch on purpose some maluses in order to show their features, but I just couldn't force myself to catch all of them :p)
RETREAM - retro dreams for Amiga, Commodore 64 and PC
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
).
