Tech demo of my game

[paraj]

Originally Posted by remz

The glitch your screenshot shows looks like if one the palette was incorrectly set: I would guess palette #1 (since if it was palette 0, the border wouldn't be black).
Because the game is in HAM, every pixel using palette #1 is shown with an incorrect color and it "fringes" up until the next color index pixel because of how HAM works. Very strange indeed.

One of the times I saw it also affecting the border, but only for a limited part of the screen (changing). Maybe in some situations you have some memory corruption (or again, maybe my amiga is going bad). If you're debugging this I'd suspect two things: Music player (probably not the issue) and OS loading routines (since you seem to be using OS to load while stuff is going on) or a combination of the two.

[vulture]

@remz

ok, that's seriously impressive m8! HAM6 and all these sprites!

Any idea if this could keep going at 50/60 fps after AI and collision were added to make a proper game or is there no cpu time left at all?

[remz]

Originally Posted by Aardvark

This demo works without glitches under GenericKick31.slave with or without Cache option. Only when running natively it crashes with cache.

Hi Aardvark, can you give me information on what hardware/OS/version/specs it crashes?

paraj crash is presumed as "non repro" and perhaps faulty hardware, so you would be the only mention of a crash thus far, which I'd like to investigate.

[rothers]

This looks amazing, what a brilliant piece of work pushing the hardware. Well done!

[remz]

Originally Posted by vulture

@remz

ok, that's seriously impressive m8! HAM6 and all these sprites!

Any idea if this could keep going at 50/60 fps after AI and collision were added to make a proper game or is there no cpu time left at all?

There is certainly a lot of CPU left for running logic and interactions.
But I'll need to flesh out a game design prior to going further.

The way it works is by cycles of 8 frames mainly busy during horizontal scrolling. When the player is not scrolling, the CPU is almost 100% free to do other things. The key will be to incorporate game logic with player movement: For example, when opening a door or a chest, we could assume the player cannot be horizontally moving during these actions.

[vulture]

that's great!

[phx]

A collection of some nice techniques here. Already looks impressive!
You are hiding problems with HAM on the left border by a big sprite? Good idea!

I just tested it on my A3000/060 and it seems quite stable to me. Only the sprite recoloring has some issues.

When I move away to the right, and then back to the start location it becomes worse, and nearly all sprites are black.

[remz]

Originally Posted by phx

A collection of some nice techniques here. Already looks impressive!
You are hiding problems with HAM on the left border by a big sprite? Good idea!

I just tested it on my A3000/060 and it seems quite stable to me. Only the sprite recoloring has some issues.
Attachment 77979
When I move away to the right, and then back to the start location it becomes worse, and nearly all sprites are black.

Yes There is a tall sprite (16x256) which will double as a health and status bar, which is used to discreetly hide the HAM fringing during horizontal scroll. Since my tiles are 16x16, 16 pixels is enough to cover and we don't see any of it.

Thank you for the report: It is the first time I hear about a sprite coloring issue on a non-AGA machine, which will certainly help me pinpoint my mistake(s).

[Aardvark]

Originally Posted by remz

Hi Aardvark, can you give me information on what hardware/OS/version/specs it crashes?

A1200, Warp1260, AmigaOS 3.2.1:

Setpatch with Cache enabled -> crash
Setpatch with Cache disabled -> works with graphical glitches
No Setpatch -> works with graphical glitches
Loaded via generic WHDLoad slave -> works without glitches

[ppill]

This is seriously impressive!

A1200 with 8 megs of ram, kick 3.1. Glitch at the start, level loads fine. Color 0 (I think) is not properly set since it shows up as pink. Same thing with cache disabled and OCS emulation set in the boot menu.

A500 1Mb chip 1,5 slow, kick 3.1. Glitch at the start (different coloured lines), level loads fine. No issues after that.

[remz]

Originally Posted by Aardvark

A1200, Warp1260, AmigaOS 3.2.1:

Setpatch with Cache enabled -> crash
Setpatch with Cache disabled -> works with graphical glitches
No Setpatch -> works with graphical glitches
Loaded via generic WHDLoad slave -> works without glitches

I would be intrigued to know if the problem would be reproducible on WinUAE using a 1260 emulation like cyberstorm PPC?

[remz]

Originally Posted by ppill

This is seriously impressive!

A1200 with 8 megs of ram, kick 3.1. Glitch at the start, level loads fine. Color 0 (I think) is not properly set since it shows up as pink. Same thing with cache disabled and OCS emulation set in the boot menu.

A500 1Mb chip 1,5 slow, kick 3.1. Glitch at the start (different coloured lines), level loads fine. No issues after that.

Thank you!
Would you be able to show a screenshot of the pink color issue on your A1200?
Did you try booting with no startup-sequence, to see if my code is having issue when something else is running?

[ppill]

Originally Posted by remz

Thank you!
Would you be able to show a screenshot of the pink color issue on your A1200?
Did you try booting with no startup-sequence, to see if my code is having issue when something else is running?

Will do.

Booted from the adf using a Gotek each time.

https://drive.google.com/file/d/1A5h...usp=share_link

Had to steal a few things from the a1200 to get the old lady running... won't have the time to put it back together tonight but it's pretty much the same, just the black shades and outlines on the coins and blobs are pink.

Also one of the vases seems to disappear when you move further off screen.

[remz]

Originally Posted by ppill

Will do.

Booted from the adf using a Gotek each time.

https://drive.google.com/file/d/1A5h...usp=share_link

Had to steal a few things from the a1200 to get the old lady running... won't have the time to put it back together tonight but it's pretty much the same, just the black shades and outlines on the coins and blobs are pink.

Also one of the vases seems to disappear when you move further off screen.

Thank you for the video.
I don't quite see the pink color issue you are describing. This is a screenshot from your video:

the outlines and blob of shadows all appear properly black:
Could you help me figure out what is buggy?

[Amiga600]

Awesome work, if you like perhaps I can feature it on my Blog, and perhaps at a later stage, when it is complete, include it in the Games Collection and Amiga Forever RP9 format

[ppill]

The video is from the a500. Haven't made the a1200 yet since I have to put it together again

[rsn8887]

I just tested it on MiSTer FPGA Amiga Core and it works just fine.

[robinsonb5]

Very very impressive - I love it! (And the music too!)

I just tried it on the MiST Minimig AGA FPGA core, and it works perfectly if I disable Fast RAM and Turbo Chip RAM - but with either of those enabled I see similar glitches to the ones in Paraj's screenshot.

[Lineof7s]

That is shockingly pretty.

[remz]

Thanks to all your help and your reports, I believe that I found the issue:
The problem was on fast Amigas, with fast RAM, I didn't wait for the blitter correctly in some cases. A naive assumption on my part that the Blitter, when running in 'HOG' mode, would occupy 100% of the chip ram bus. I should have paid heed to the wise people saying "Thou shall always wait for thy blitter.".

Here's a new version of the ADF with the glitch fixed:
Hopefully this will make it work flawlessly on *any* amiga models.

Bonus: It even runs on the Vampire V4! However, there is a weird color glitch on the HAM tiles when scrolling vertically. This is so unexpected that I would be inclined to think it is a small hardware/fpga glitch on the Vampire itself in this case. Maybe the HAM mode was not tested as thoroughly.

https://eab.abime.net/attachment.php...1&d=1675381013