Hamulet test - Large HAM bobs

[Karlos]

I didn't want to derail the thread too far, so any thoughts on the raycaster are better posted here https://eab.abime.net/showthread.php?t=106646

[hammer]

Originally Posted by Karlos

If you want to see what HAM8 can do with enough CPU power, I recommend Mateusz Staniszew's "funtime raycaster"...

[ Show youtube player ]

RGB, Mip Mapping and shadow maps.

I'd like to see that on a PiStorm.

There's Quake in PiStormEmu68 enhanced A500 HAM mode.

[kremiso]

Originally Posted by remz

Hello coders,

While still working on Hamulet, I was experimenting with the possibility of drawing HAM bobs and wondering if this has been attempted before:
I captured a short video snippet at 50 fps to show a sort of proof-of-concept, running on Amiga 500 OCS (1MB chip) here.

One of main concern of HAM bobs is the large amount of chip memory they require, but also how to manage fringing. You can see in my video that the fringing is barely noticeable. However, my 'bobs' are not moving: they are stationary. In this state, their usage in a game would be mostly for animated stationary objects, or other innovative ideas.

Also, I've set one of the HAM index colors to show a copper gradient which scrolls at a lower speed to create a parallax effect. I do not know if this has been attempted on a HAM screen before.

I wanted to try using the blitter to draw a sort of 'parallax layer' using a mask but the runtime cost seemed to be high compared to the potential gameplay benefit.



[ Show youtube player ]

what could be the better game-genre to test this awesome tech beauty?
i was imagining some end of dungeon jrpg big boss battle

[saimon69]

Rerally, you should use this engine for a JRPG, not too much screen action there so will fit like a glove

[Photon]

Originally Posted by hammer

There's Quake in PiStormEmu68 enhanced A500 HAM mode.

While raycasting is not really related to thread, it bears some resemblances being static and not full framerate (see my previous comment).

In response to this tho, if you really want to see x on y "for the tech", why replace both x and y? Quake is already running on another platform x running another software y, and on real Amiga with RTG. I have such a hard time understanding this. It's also separate from the fallout, namely wishing devs would develop for platforms other than Amiga.

No discouragement, just reflecting since topic is large HAM bobs. Cheers.

[DisasterIncarna]

Originally Posted by kremiso

what could be the better game-genre to test this awesome tech beauty?
i was imagining some end of dungeon jrpg big boss battle

a flip screen, dizzy type game?

[mc6809e]

Amazing!

How many cycles left for each frame? So impressive.

[Nebulon]

Originally Posted by malko

^ I am almost sure that not (so only HAM6) but I can't remember if pushing the A500 & A2000 to 2MB Chip permitted the HAM8 mode :
http://obligement.free.fr/articles/megachip2000-500.php

HAM8 is AGA only.

However, I'd like to see the author of Hamulet continue on with OCS HAM6 and see how far he can take it. AGA isn't as efficient as OCS or ECS.

[remz]

Originally Posted by Nebulon

HAM8 is AGA only.

However, I'd like to see the author of Hamulet continue on with OCS HAM6 and see how far he can take it. AGA isn't as efficient as OCS or ECS.

Rest assured it is definitely my goal for Hamulet. My goal was that it runs on an 1985 Amiga 1000, however with 512KB of chip.
(I think the original 256KB chip, if the game is "os friendly" and hd-installable, is extremely limited especially if you are thinking about a scrolling HAM screen ).

Eventually a future game or a sequel could be CD32/A1200 with many enhanced features using AGA and HAM8. But one thing at a time

[Nebulon]

Originally Posted by kremiso

what could be the better game-genre to test this awesome tech beauty?
i was imagining some end of dungeon jrpg big boss battle

First off. Brilliant work. You're actually making history here.

I've scoured the existing Amiga library, and I'm unaware of any other program that used Copper parallax while in HAM6 mode.

If you can, try to keep your blitter usage at this time within 512k. If you go above that, you'll lose Amiga 1000 compatibility (you have a chance here to showcase just what that 1984/1985 hardware was capable for future historians). You can always make a super-version of what you have here as a sequel, some time after you figure all this stuff out on the OCS.

So, if I'm interpreting this correctly, those big boss things are blitter-generated and cannot rove around. No problem. Just use them as you have them here. For example, you could do something like in R-Type where your player moves around the boss and shoots away objects that are attached to its exterior. Or you could use these large objects as cool things to walk past or walk around (like in Metal Slug).

I'm guessing you've already read the Amiga hardware reference manual and know what I'm about to write, but you have many approaches that you can take. With OCS, the blitter and copper are cycle-interleaved with the MC68000 CPU while Agnus is in normal operation mode. So you should be able to set up scenarios where Agnus is adding 'icing on the cake' with little CPU intervention. The sprites are also cycle-interleaved with Agnus, so those two should never fight for RAM either (unless Agnus is switched to aggressive mode).

I'm very happy to see that you're using racing-the-beam techniques. This is actually part of the Amiga's hardware lineage and is something that few programmers utilized much or at all. Now that Joe Decuir's explained the Amiga's design philosophy, I think programmers are beginning to discover new ways to unlock the power within the Amiga. There are some good Byte magazine interviews with Jay Miner that should also provide some hints as to the most efficient ways to tap into what the Amiga has to offer.

Again, great work.

P.S. Is there a .ADF file available with a demo of the large BOBs that I can try out on real hardware (maybe an additional one that works on a 512k Agnus chip as well)?

[copse]

Originally Posted by Nebulon

Now that Joe Decuir's explained the Amiga's design philosophy, I think programmers are beginning to discover new ways to unlock the power within the Amiga.

Is there any particular explanation you are referring to?

[alexh]

Originally Posted by copse

Is there any particular explanation you are referring to?

He said the Amiga design philosophy was to be able to "animate cartoons in hardware"

[copse]

Originally Posted by alexh

He said the Amiga design philosophy was to be able to "animate cartoons in hardware"

I'm not sure how just saying that at this point really unlocks any mental possibilities. If he'd described how the bitplanes and blitter and copper had been envisioned to be used in a way to do something technically viable and insightful that was never explained to the community.. then perhaps.

[Nebulon]

Originally Posted by alexh

He said the Amiga design philosophy was to be able to "animate cartoons in hardware"

That's the ultimate cut-down version. Kind of like saying Star Wars is about two robots and a space ship that shoots at another space ship. Pew pew.

I was referring to the Amiga's racing-the-beam lineage along with blitter and CPU being cycle-interleaved in the A1000, 500, and 2000, re-usable sprite engines that are also cycle-interleaved with the Agnus (again, avoiding RAM contention in standard Blitter operation mode), state-machine audio generators (again, a smart design for reducing CPU overhead), dual bus, his explanation of why the Copper even exists and what it's the evolution of, display list-based graphics, etc....

Put together Joe Decuir's talks with the info that Jay Miner's provided in multiple Byte magazine articles and it's clear that the approach that is being taken for Hamulet is a great example of people effectively using the tools that the Amiga hardware provides (in this case, one that's often overlooked).
His overview of where he and Jay began and the iterations that led to the Amiga are key to understanding how to squeeze the most out of the platform.

See:
[ Show youtube player ]
[ Show youtube player ]
https://www.blitter.com/~nebulous/amiga-articles.html
[ Show youtube player ]
[ Show youtube player ]
https://archive.org/details/amiga-ha...al-3rd-edition
[ Show youtube player ]

He also mentions a few notable books, including "The future was here." And programmers might want to take a look at "Bare-metal Amiga programming."

A member of Scoopex has an assembly language course on YouTube. He has some interesting observations on the blitter and how fast it pushes pixels (considerably faster than the MC68000). The former of the two books discusses efficiency of operations of the blitter (as does Joe Decuir).

[turrican3]

This is a complete sorcery !!! amazing !!

[Nebulon]

Originally Posted by remz

Rest assured it is definitely my goal for Hamulet. My goal was that it runs on an 1985 Amiga 1000, however with 512KB of chip.
(I think the original 256KB chip, if the game is "os friendly" and hd-installable, is extremely limited especially if you are thinking about a scrolling HAM screen ).

Eventually a future game or a sequel could be CD32/A1200 with many enhanced features using AGA and HAM8. But one thing at a time

Take your time. No rush. Just the process of what you're doing is important and shows other programmers out there some new possibilities (and might work to inspire more great projects). Posting some source code might be an idea to speed people along so that they can make neat things for you to eventually play (lets face it, people eventually get bored of their own work; I know I do).

512K would be the actual chip RAM amount for the Amiga 1000 (it was only starved for RAM to meet a price point in the magazine ads of the time). The other 256kB of chip RAM was easily available at time of purchase (the A1050).

The BOB moving over HAM thing did happen back in the day. The solution to fringing that was used was to make a thick black border around the moving object to hide the fringes as it traveled over the HAM background. Of course, for Hamulet, a stationary large BOB would work fine and the ones you've made look great. It could be something that blocks a character's path. For example, walking into a large open room, lighting a torch on the wall, and seeing a massive tentacle. Culminating in the reveal of a large Cthulhu squid-looking thing that's blocking your path. So an idea might be to have the player character slide a pot onto a tile to open a side door, break open another pot beyond that door to get a piece of cheese, give the cheese to the mouse that I saw in your earlier demo, have the mouse fetch a key for the player, use the key to open another door and throw a switch that teleports the monster away and unblocks the path to the next area.

A game that's comprised of puzzles like this would be ideal for the 'engine' that you've made. For example, the exact same movement, sound, animation, etc... that you've already demonstrated with a goal of some important object at the base of an 8-layer dungeon. Each level has a room guarded by a large stationary boss (BOB object). And each requires that you puzzle your way past that boss and into that room. Each room contains one of eight pieces (shards or what-have-you). When you reach the lowest dungeon and the final room, you plug the eight shards into eight sockets on the walls to open the final room and claim the object. Then you're teleported back to the village, complete with congratulatory artwork like the excellent intro art in your demo. Roll credits.

Something like that.... I'm just making this stuff up off the top of my head.

In my travels, I found some links you might like (I'm sure you know all this already, but some out there might find them interesting):
https://www.markwrobel.dk/post/amiga...dma-revisited/
http://amigadev.elowar.com/read/ADCD...e/node02D4.gif
https://www.markwrobel.dk/post/amiga...-letter12-ham/

P.S. If you ever need any help proof-reading the on-screen text for the game, just let me know. Nebulon1212@gmail.com

[skan]

Originally Posted by remz

Rest assured it is definitely my goal for Hamulet. My goal was that it runs on an 1985 Amiga 1000, however with 512KB of chip.
(I think the original 256KB chip, if the game is "os friendly" and hd-installable, is extremely limited especially if you are thinking about a scrolling HAM screen ).

Eventually a future game or a sequel could be CD32/A1200 with many enhanced features using AGA and HAM8. But one thing at a time

...or you can use the Dragon's Lair trick to get extra 256KB from WCS on the A1000.

Impressive stuff indeed, congrats!
I'm curious to see what you can do with it!

[mc6809e]

Originally Posted by skan

...or you can use the Dragon's Lair trick to get extra 256KB from WCS on the A1000.

Impressive stuff indeed, congrats!
I'm curious to see what you can do with it!

With the bonus that those accesses to that 256k sram are contention-free.

Wish they'd kept at least some tiny bit of sram on the 500/2000. Even 256 bytes would have been useful.

[REAKTOR BEAR]

Rock on dude!

[carlosgod]

Originally Posted by saimon69

Rerally, you should use this engine for a JRPG, not too much screen action there so will fit like a glove

Damn, why didn't I think of JRPG? The first thing that comes to my mind was some sort of shoot-em-up when this engine is actually perfect for SNES Final Fantasy remake! Big, colorful world map using the tile system as in Hamulet and the protagonist sprite is only thing that moves around the screen.




Then when we switch to the turn-based combat scene all the bad guys are giant HAM bobs and the protagonist groups are all sprites.





May be the sequel to Hamulet could be a J-RPG! And the original game could be like a dungeon raiding mission within the bigger game...