|
Game Under Again by Lemon.
[nfo]
|
||||||||
|---|---|---|---|---|---|---|---|---|
|
|
|||||||
|
popularity : 63% |
|||||||
alltime top: #7202 |
|
|||||||
added on the 2025-09-21 09:04:00 by Hannibal  |
||||||||
popularity helper
comments
Making Magic happy always +1 in my book 😁
Great effords in perfectionising earlier released productions!
Thats the way!
Great effords in perfectionising earlier released productions!
Thats the way!
cool another must watch production :)
Elitez
It's a hallmark of quality when a prod entices you to fire up the DMA debugger. ;)
I don't understand the use of 7 1/2 bitplanes, isn't it easier to use 7 bitplanes + change bit 15 in BPLCON4 ?
Fantastic stuff once again. I guess this must truly be game over/under for this challenge. Congrats! I still need to fire up the debugger again and figure out what the new trick was. I must admit it wasn't immediately obvious :-)
Regarding the maximum visible width, Photon helped me do some hardware testing, and if I’m getting this right, our conclusion was that that 369 pixels were actually visible on a CRT, the reason being that even though the RGB signal can include 384 pixels, 15 of them are before the HSYNC high signal that turns the beam on. I wouldn't be at all surprised if there was more to this though.
Regarding the maximum visible width, Photon helped me do some hardware testing, and if I’m getting this right, our conclusion was that that 369 pixels were actually visible on a CRT, the reason being that even though the RGB signal can include 384 pixels, 15 of them are before the HSYNC high signal that turns the beam on. I wouldn't be at all surprised if there was more to this though.
Looks absolutely delicious on my A1200+1084 setup.
Gigabates, the main improvement since And One Up The Sleeve was when to change between bitplane and HAM displays. In AOUTS I switched to bitplane mode at the right side of the screen. In GU/GUA I switched to bitplane mode in the middle of the screen, and switched back to HAM after the 16 columns were shown. That gave me 64 extra pixels to spend moving sprites and setting sprite colors, and it meant I only had to dynamically move 3 sprites and set 6 sprite colors throughout the raster line - the other sprites were fixed in position, and their colors only had to be set for each row (i.e. every 4 raster lines), which I could mostly do with the CPU.
I also changed the copper sync point in each raster line to be in the middle of the frame instead of during the border. This meant that there were DMA cycles free for the CPU both at the border and at the middle of the raster line, which gives a total of 8 shorter CPU activity spans per row where instructions run.
The CPU loop per row is only 12 instructions long. 3 of the 4 raster lines in a row are using divu #$1,d0 and lsl.w d0,dx to skip past the audio dma cycles and stay stable - the Gigabates trick. The CPU sets a total of 22 used colors - 21 of them with a single movem, followed by a single move for color 31. The movem command itself takes more than a whole raster line to execute, but I timed it so it starts setting the colors during the middle CPU activity span, and it sets left-side colors first and right-side colors last, so all colors are set by the time they are needed for the next raster line.
I also changed the copper sync point in each raster line to be in the middle of the frame instead of during the border. This meant that there were DMA cycles free for the CPU both at the border and at the middle of the raster line, which gives a total of 8 shorter CPU activity spans per row where instructions run.
The CPU loop per row is only 12 instructions long. 3 of the 4 raster lines in a row are using divu #$1,d0 and lsl.w d0,dx to skip past the audio dma cycles and stay stable - the Gigabates trick. The CPU sets a total of 22 used colors - 21 of them with a single movem, followed by a single move for color 31. The movem command itself takes more than a whole raster line to execute, but I timed it so it starts setting the colors during the middle CPU activity span, and it sets left-side colors first and right-side colors last, so all colors are set by the time they are needed for the next raster line.
When it enters the baller mode, I think I wet my pants or something...
Cool, I didn't know about the top bits in BPLCON4, that would be even faster!
I wonder why Blueberry saw 376 and you and Photon see 369. Maybe some hardware sees the hsync signal and use previously received colors on the hardware Blueberry used? This is fascinating.
I wonder why Blueberry saw 376 and you and Photon see 369. Maybe some hardware sees the hsync signal and use previously received colors on the hardware Blueberry used? This is fascinating.
Mandatory thumb.
Always great to see a new prod from Lemon.
Again a thumb :3
this is going crazy :)
Nice!
Ok, you hold the record for the most columns, but what about the record for the most 4x4 RGB blocks? :)
Quote:
Cool, I didn't know about the top bits in BPLCON4, that would be even faster!
Yeah, the color switching provided by BPLCON4 is an extremely useful (and probably quite underutilized) feature of AGA. The layer polarity of the 8 layers in the checkerboard effect in No-CPU Challenge is controlled entirely through BPLCON4. :)
Quote:
I wonder why Blueberry saw 376 and you and Photon see 369. Maybe some hardware sees the hsync signal and use previously received colors on the hardware Blueberry used? This is fascinating.
I don't remember exactly which hardware I used to measure the maximum width back then, but most likely it was a MicroniK SCANDEX scandoubler.
I have brought my old 1084 down from the attic. It needs a bit of cleaning, but then I'll do some testing on that one and report back.
Like it! Thanks
Closer to perfection or already beyond?
I thought this was a step up from the old Game Under, it even has the same music (I think) but when the rotozoomer went fullscreen, I was deeply impressed!
Maybe we're finally done soon :-)
submit changes
if this prod is a fake, some info is false or the download link is broken,
do not post about it in the comments, it will get lost.
instead, click here !
I then wanted to see how fast the A1200 was compared to A500, and with a few standard A1200 optimizations (CPU cache friendly loops, 32-bit aligned data, using 4x bitplane fetch, and using 7 1/2 bitplanes on screen), I reached over 12000 chunky pixels, enough for maximum overscan with 3x3 pixel chunks.
I ended up refactoring the OCS code, so now it is perfectly cpu stable - In the DMA debugger it is beautiful now! Plus I pushed the record from 92 to 94 columns, which *should* be the maximum visible width from the Amiga display chip.
Finally, I single-filed it to make Magic happy (not really - I did it because Virgill's A1200 doesn't have a working DF0 :-). And I single-filed And One Up The Sleeve, too - but I didn't Aga-fix that one.