Tech demo of my game

[Samurai_Crow]

Originally Posted by saimon69

Wonder if a turn based JRPG a la Final Fantasy or Shining Force is a good fit for this

It might be if we could drop the screen resolution to fit the number of sprites available. I think ECS or AGA can do that but not OCS. 256×200 NTSC maybe? Maybe centering 16 pixel sprites over a 32 pixel background tile?

I liked Shining Force too. It would be great to have that on Amiga. The scrolling would be back and the sprite on the left side would be needed to cover the color fringes though.

[saimon69]

Originally Posted by Samurai_Crow

It might be if we could drop the screen resolution to fit the number of sprites available. I think ECS or AGA can do that but not OCS. 256×200 NTSC maybe? Maybe centering 16 pixel sprites over a 32 pixel background tile?

I liked Shining Force too. It would be great to have that on Amiga. The scrolling would be back and the sprite on the left side would be needed to cover the color fringes though.

Since player and enemies move on turns, that would maybe make simple to change between animated tiles when still and sprites while on motion
(then there are the attack scens, but could be done with bobs in regular resolutions)

[faz]

Originally Posted by Samurai_Crow

Memory: The units must all be loaded at once due to the utter randomness. Fast memory is required because Chip RAM cannot hold them all. TC:AGA has 1.5 MB of compiled binary for the code and variables alone. 128k of stack space for the recursion of the pathfinding algorithm alone.

2 additional bitplanes, 4x the resolution and probably double buffered. Thats like 10 times framebuffer size alone on a machine with chipmem 'only' quadrupled.
I get your point though. I think i'm pretty naive when it comes to the chipmem limitation of OCS hardware.
One ham6 buffer roughly 60k and same sized buffer for tiles and object for a total of 320 (=20x16). 320 sprite animation frames (3+1 col) =~16k, one mod + sfx 80k, additional buffer (copperlists, ..) 40k -> 256k chip with code, variables, stack fitting in 512k slow. BINGO! .. I must be missing something!?

Originally Posted by Samurai_Crow

The sprites look similar, yes. To mandate no more than 8 unique images per tile row, would be a requirement that would limit the unique randomness of the game.

I have it as just 4 unique per row, otherwise you'd probably break the 12 colors/line trick to make them look like bobs. I was thinking to distribute objects between bobs and sprites, bobs mostly static and sprites preferably used for objects which amass. And you need a bob fallback for the sprites in case more than 4 unique are displayed to not get restrict to 4 in total. Quite a uncool mess, the more I think of it.

Originally Posted by Samurai_Crow

Projectiles like arrows from elves, flames breathed by the red dragon, acid from the green dragon and the manticore's tail overlap the background tiles. The arrow launches over the top of friendly units as well. Also, the optional summon magic and ball lightning project out of the wizard. That also overlaps background tiles.

Some are the same effect with a different texture applied iirc. No idea how to solve in this context yet.

Originally Posted by Samurai_Crow

Chunky to HAM8 has been slowly done on AGA. That might be possible without animation.

Sounds scary. Outline with base color would fix one half, next tile the other. But to outline in a tile just 16 px in size is far from great thou.

[Samurai_Crow]

Originally Posted by faz

One ham6 buffer roughly 60k and same sized buffer for tiles and object for a total of 320 (=20x16). 320 sprite animation frames (3+1 col) =~16k, one mod + sfx 80k, additional buffer (copperlists, ..) 40k -> 256k chip with code, variables, stack fitting in 512k slow. BINGO! .. I must be missing something!?

Animted sprites need more than one frame in RAM. All the frames are in RAM. That's what takes the most space. To decompress animation frames from Fast RAM would cost CPU time even using anim-brush formatting.

Originally Posted by faz

I have it as just 4 unique per row, otherwise you'd probably break the 12 colors/line trick to make them look like bobs. I was thinking to distribute objects between bobs and sprites, bobs mostly static and sprites preferably used for objects which amass. And you need a bob fallback for the sprites in case more than 4 unique are displayed to not get restrict to 4 in total. Quite a uncool mess, the more I think of it.

Color cycling is difficult on HAM backgrounds too. Walls and items often use those. Especially if you play with Archonian power points.

Originally Posted by faz

Some are the same effect with a different texture applied iirc. No idea how to solve in this context yet.

Chunky images rotated and animated in a matter of a second or two by the CPU into a planar animation as a sound effect loads from the hard drive and plays is how James did it. In HAM6 you have to figure out the overlay technique. If we hadn't used up the sprites by now, that would've been handy but we'd need to use a different effect anyway.

Originally Posted by faz

Sounds scary. Outline with base color would fix one half, next tile the other. But to outline in a tile just 16 px in size is far from great thou.

Yes. Figuring out how to rotate and overlay without using BOBs is the graphical limit. TC only uses 2 sprites because they are too inflexible and few. It uses CPU-blitted BOBs and tiles instead. This drives the CPU cost to well above the bandwidth limit of OCS.

[malko]

Originally Posted by ross

[...] I simply didn't want a general user to think that miraculous things can be done with your engine. [...]

Too late

[faz]

Originally Posted by Samurai_Crow

Animted sprites need more than one frame in RAM. All the frames are in RAM. That's what takes the most space. To decompress animation frames from Fast RAM would cost CPU time even using anim-brush formatting.

A Sprites has roughly 4 bytes + additional color information of 6 bytes per line. 160b per frame. How many frames for a "full" animation, maybe 3-6? Think you can fit enough for rich gameplay.

Originally Posted by Samurai_Crow

Color cycling is difficult on HAM backgrounds too. Walls and items often use those. Especially if you play with Archonian power points.

Reserve a base color for highlighting, then let it pulsate on a frame-basis for instance. Power/boost points are static during the game so you can create them during map generation. You could also redo if color deviation to the base tile is too high, use white/blacklists for tiles matching or not.

Originally Posted by Samurai_Crow

Chunky images rotated and animated in a matter of a second or two by the CPU into a planar animation as a sound effect loads from the hard drive and plays is how James did it. In HAM6 you have to figure out the overlay technique. If we hadn't used up the sprites by now, that would've been handy but we'd need to use a different effect anyway.

This almost screams for an overlay sprite. Same for all the other overlay effects (heal, dmg, exorcism etc). I would go that far to reserve a sprite for these things. With 'idle' frame bobs you could make room for it in case it get tight displaying the rest of the animated sprites in the path.

[Samurai_Crow]

Originally Posted by faz

A Sprites has roughly 4 bytes + additional color information of 6 bytes per line. 160b per frame. How many frames for a "full" animation, maybe 3-6? Think you can fit enough for rich gameplay.

The wizards have the longest animations at 24-32 frames each. Also, there's an additional frame that could be separated from animations for a dead unit.

Also, copper moves are 4 bytes each so you'd need 12 bytes for 3 copper moves.

Originally Posted by faz

Reserve a base color for highlighting, then let it pulsate on a frame-basis for instance. Power/boost points are static during the game so you can create them during map generation. You could also redo if color deviation to the base tile is too high, use white/blacklists for tiles matching or not.


This almost screams for an overlay sprite. Same for all the other overlay effects (heal, dmg, exorcism etc). I would go that far to reserve a sprite for these things. With 'idle' frame bobs you could make room for it in case it get tight displaying the rest of the animated sprites in the path.

Agreed. A pulsating base pair fits but BOBs are tricky on HAM6. They need something to avoid fringes to the right side. Nothing else will do but BOBs.

[buzzybee]

@remz: Congratulations on some well-crafted visuals in your demo. I loved the use of dynamic sprites and colors on top of HAM tiles from the very first moment I saw a video of your demo some days ago on youtube. Exceptional!

I wish you the best of luck in finding a suitable game design for your tech. May I suggest focusing on gameplay mechanics that emphasize the strength of your tech. If its colors and real-time lighting what you can do exceptionally well, make that an integral part of the game experience.

I guess it might be worthwile to enhance the versatility of your tech. Adding moving objects feels crucial to me, otherwise you might be too restricted to create an interesting gameplay experience.

From what I read in this thread, it feels like it is technically difficult to move sprite-based objects on the x- or y-axis as you cannot simply change coordinates. If so, you might want to emulate x- and y-movement of small ingame objects by using a tile based animation approach comparable to common techniques used on ZX Spectrum and such machines.

This is done by pre-rendering mobile objects into a set of word-based tiles. Each tile displays the object, moved one or two pixels left/right/up/down. You then just need to blit one or two tiles into your bitmap each frame update, and so create the illusion of a moving object. Almost like in a flip book.

If implemented cleverly, you should be able to add moving objects and simultaneously avoid HAM colorbleed, as the tiles are always copied onto word-based boundaries.

[Thorham]

Games like Advance Wars (GBA and NDS) and Fire Emblem (GBA) seem ideally suited for this graphics engine.

[gimbal]

A bomberman style game might be a good kicking off point. It needs to be something on the smaller scale because during the first game it's going to be half time working on the game and half time reworking the tech.

[carlosgod]

Originally Posted by gimbal

A bomberman style game might be a good kicking off point. It needs to be something on the smaller scale because during the first game it's going to be half time working on the game and half time reworking the tech.

Agree - I think Bomberman Party Edition (PS1) level of graphics might even be doable with this engine, though you would have to deal with the pseudo 3D element and the gameplay would need to be toned down a lot as you mentioned.

https://www.alamy.com/bomberman-worl...363749437.html

Still, this could be the first ever attempt by anyone to port a PS1 game to the stock A500. Mind blown.

[REAKTOR BEAR]

Absolutely amazing stuff.... Rock on dude!

[remz]

I'm making progress and adding enemies and gameplay elements, hopefully planning to have a playable demo in the coming weeks or so.
There is so much to do!

[albino]

Well done, that's impressive....

[hexaae]

Amazing work. Hope to see a game out of it one day...

[Djay]

Wow! Great tech demo... kinda remind's me of 'Enter the Gungeon', the light sourcing idea is pretty cool and could be integrated into level design, where puzzles could be light dependant.. which leads me to concept, personally I think the Amiga could do with a loot shooter, think Destiny with random loot and weapon/gear progression. Structured campaign and then repeatable content to reach endgame final mission. Embrace modern mechanics with spreedrun times and unlockables.

[carlosgod]

Originally Posted by remz

I'm making progress and adding enemies and gameplay elements, hopefully planning to have a playable demo in the coming weeks or so.
There is so much to do!

Hi - just wondering how things are going with the development, and whether you were able to resolve the issue of enemy objects moving around the screen without causing fringing effect (or perhaps that was never a problem in the first place?).

Really excited to see this tech working. I've always felt that the lack of interest in HAM mode by Amiga devs during the early 90s was a huge, huge missed opportunity - esp since the Amiga had to compete with the likes of SNES, Megadrive and early PCs at the time and was failing on multiple fronts (Except may be sound). This project would prove that the A500 could have potentially remained competitive for a longer, may be add 3-4 more years to its lifespan (or in the best case scenario, expired at the same time as the SNES which was early 2000). It would also kick off a new wave of retro Amiga gaming development! 4000+ colors for OCS and 250,000+ colors for AGA would be the new base line!

[remz]

Hi carlosgod,

I've been continuing to work on the game and adding various elements. At the moment I am focusing on making a sort of "playable demo" for magazine.
I am managing to have minimal HAM fringing and keeping the framerate always at full speed.

I hope to be able to show something soon to all of you!

[carlosgod]

Originally Posted by remz

Hi carlosgod,

I've been continuing to work on the game and adding various elements. At the moment I am focusing on making a sort of "playable demo" for magazine.
I am managing to have minimal HAM fringing and keeping the framerate always at full speed.

I hope to be able to show something soon to all of you!

Glad to hear that things are going well. Look forward to the playable demo!

[remz]

Originally Posted by carlosgod

Glad to hear that things are going well. Look forward to the playable demo!

Good news: the playable demo of Hamulet is available for download in the latest issue #10 of the WhatIff magazine: http://whatiff.info/

Feel welcome to give it a try, and thank you