Posted By
Mad
on 2019-08-19
21:11:44
|  Re: Alpharay Plus/4 just released at Evoke 2019
To make me ungodly again.. Some of the stuff used which is just remembered.. I think there was more involved but that's the parts I remember just now..
Edit: my tabulators are not shown!! :D Perhaps I should do a website with some "indepth explanations".. Hope that here already helps..
The decission for bitmap mode was just made because of the challenge I suppose, I don't remember the reason. Charactermode graphics where taken to a limit with Pets Rescue (perhaps period).. I think an R-Type Leo video on a Playstation was the thing that triggered this decission for me.. I was sure that bitmap mode will lead to very good graphical results, even comparable to early arcades..
Since the $ff1a/$ff1b bitmap pointer just display the bitmap with a different offset. The sprites can be painted in a slower way.. (ranges from 2nd to 5th frame most time more like 25 fps to 12fps..) So the scrolling is done with 50 Hz and the sprites are painted slower.. Bubis HSP saved the day because it too just delays the readout of the colorram, which is pretty nice in combination with $ff1a/$ff1b, both, bitmap and colorram pointers, give a good and almost fully working "synergy" there.. :)
Funnily we didn't have to take care of the rasterbeam position at doing the sprite updates.. It's almost not noticable that the sprites are modified (painted / cleared) directly on screen..
Here some of the things I remember from the technical side..
1. Scrolling
- features:
-- single speed (25Hz), double speed (50Hz), tripple speed (75hz)
-- right scrolling, down scrolling, rightdown scrolling
- is done in interrupt at 50 hz.
- Bubis HSP trick used for X Scrolling
-- after 40 columns the whole colorram gets copied 40 chars further in a nested interrupt
- Y Scrolling is done the usual $800 colorram copy in a one framed way, but in a nested interrupt. (sometimes just very very few rasterlines left, sometimes too few)
- of course the softscroll registers are used for fine scrolling 8 pixels
- the appending on the right was easy.. At bottom there is much trickery involved, and the status bar hides some of the build ups..
2. Single Buffer
- We just have one $2000 bitmap displayed and one $800 colorram used. So just a single buffer.. 
- Scrolling is done via HSP and single frame copy of colorram
- The Singlebuffer Sprites (i would need a graphic to fully explain that) Perhaps CPC, Spectrum and other people can use that or even use it already..
-- There is a 40x25 char matrix used in the background to tell the type of the displayed characters
-- There are several bits for every char entry in this matrix
--- one bit tells if there was a sprite in the last frame on this position
--- one bit tells if there is a sprite in the current frame on this position
--- the other 6 bits are also used for shots (in the same manner), background element types and collisions and other stuff
-- So here comes the bit logic..
--- first I paint the sprite of the current frame after that the same sprite at the last frame is cleared.. working as follows:
--- if sprite clearing
---- just check if there is the sprite bit is set for the current frame if so don't clear
---- else if sprite bit is set for last frame then clear
--- if sprite painting
---- if not current frame sprite bit is set. Just store the 8 bytes there no masking. (extremely fast painting)
---- if current frame sprite bit is set.. Do combine the sprites by color clash reduce and masking.
--- so this way only the left overs of the sprites are cleared (the "borders") and we can reduce the need for masking or the need for color clash fixes.
-- Color clash reduce is not done if the sprites share the same luminances
-- I had to use the $80 bit of the luminance ram, too for notifying background elements because of the colorram copies (not full AGSP just HSP)..
3. Color Clash Reduce
- If sprites overleap. We just take the both brightest colors of both sprites and paint some checker 2x2 pattern instead of the darker colors. (Have to check that again in the code)
- Ingo has some more advanced approach used in the past. But this approach already did a lot.. The checkering of the colors was the key to give an impression of mixing. And the brighter colors are always more noticable.. Have to check the code for it.. I will update this here then.. At least the checker pattern is the key! :)
4. Sprites
- X Shifting for non 8x8 movement  .. Done with tables as usual no masks or preshifts.. (feel free to ask how if it's not clear)..
- Support for 256 (max 32x40 pixel) sprites in memory which sometimes is almost used (176 or something have to check later).
- Automasking (bit %00 means it's transparent) inspired by Mike Dailly (as Degauss told me)
- Luminance animation possible
- 2 free colors per single sprite, and white
- 17 Sprites possible sometimes all visible.
- Char Collisions and after that rectangle collisions for more precission
- X flipping on the fly for all sprites. For some sprites (16x16 ones) also Y Flipping.
5. LevelData
- RLE decrunching of the levels on the fly.
- 16x16 tiles
- A level can be any width (like 1024) and 64 in height (like 2050x64 tiles)
- There is a special packer "opcode" to notify y mirroring of the 16x16 tiles. So we don't have to duplicate graphics data for mirrored tiles.
- Since we have many empty parts in the level the RLE does a fairly good job on the memory side..
6. Bubis HSP
- DMA delay never done before on Plus/4. Something Ingo said that it's an historical achivement on the machine.
- Doug: Yes it can be used on character screens. This feature can be extremely useful later on! But that's Bubis part to explain somewhere.
7. Scripting language
- Around 64 Opcodes
- Inline assembly supported
- Almost all animation in the game is done with it, even the "get ready" letters, joystick queries and the endbosses
- Supports different enemies and behaviours for different difficulty levels of the game
8. 50 Hz Player Sprite
- Just possible because of the use of a single buffer engine. Double Buffered it would be very hard to implement performantly..
- Supports 32x24 pixel sprites
- Player Sprite is updated and controlled every frame
9. Small Split Screen for the Status Bar
- not so advanced but is solid for x and y scrolling.
- seems there was just one cycle left after storing all registers at a badline. Yape 1.1.6 got problems with this one cycle it seems.
## -- 10. Big Lasers later in the game done by just adding and removing single "chars" on the bitmap screen .. And other stuff...
Have fun! And perhaps that can inspire someone.. Some ideas could perhaps be useful for other games..
|
