GRIND : a Doom-like, first person shooter for a500!

[TCD]

Originally Posted by Tsak

• Being able to play one level after the other with stats carrying over (without having to manually select each map anymore).

Next stop: Amiga Half-Life

[DisasterIncarna]

Originally Posted by TCD

Next stop: Amiga Half-Life

in order of complexity, i think a Duke3d'alike would be next in step before a HL1'alike came to be

[TCD]

I was referring to this aspect of Half-Life:

Half-Life has no levels; it instead divides the game into chapters, whose titles briefly appear on screen as the player progresses through the game. With the exception of short loading pauses, progression throughout the game is continuous, with each map directly connecting to the next, with the exception of levels involving teleportation.

[DisasterIncarna]

ooooooooooooh.

[samo79]

Well done boyz ;-)

[Karlos]

@tsak

I mentioned this elsewhere, but perhaps it's better put here. Recent experimentation with Akiko suggests it's a good option for reduced colour depth C2P on vanilla 68020 hardware. The game already runs very well on vanilla AGA A1200 even with software C2P but I imagine it cout run even smoother on a CD32. It seems in the spirit of being designed for the platform, anyway.

[Tsak]

Originally Posted by Karlos

@tsak

I mentioned this elsewhere, but perhaps it's better put here. Recent experimentation with Akiko suggests it's a good option for reduced colour depth C2P on vanilla 68020 hardware. The game already runs very well on vanilla AGA A1200 even with software C2P but I imagine it cout run even smoother on a CD32. It seems in the spirit of being designed for the platform, anyway.

I'm well aware of the Akiko thread (and so does my team)
The issue is I have no idea how complex bringing Akiko into the mix would be. And being a CD32 exclusive feature also means this is a pretty niche priority. Before we consider going there we have a few other things to manage, like ISO exports and CD32 controller support. And whatever 020/AGA optimizations we can also find. (supporting higher fetch modes is already done btw but there's much more to come!)
Besides those, further optimizations to help performance on OCS is probably an even higher priority (while this is probably even more difficult).

Other than that I'm pretty positive personally in regards to Akiko. Whatever optimizations we can find is a good thing.

Notes:
- Afaik KK used his own blitter assisted C2P on the Dread engine. Would be interesting to see how this compares vs your other tests.
- My doors are open to anyone who would like to help in this regard, f.e. provide an even better optimized C2P module (say with added Akiko support) which we can use.

[Karlos]

Originally Posted by Tsak

- My doors are open to anyone who would like to help in this regard, f.e. provide an even better optimized C2P module (say with added Akiko support) which we can use.

We can talk on the other thread if you like.

[boemann]

Isn't one of the optimizations Grind do that it doesn't do a full c2p. It only does it half way by converting 160x100 chunky to 320x100 planar with 4 chunky pixels being expanded to 4 times 2 pixels. Thereby only having to do half as many conversions.

At least that is how I imagine what it does.

If that is true then Akiko conversion needs to be twice as fast to be better overall

[Mathesar]

Originally Posted by boemann

Isn't one of the optimizations Grind do that it doesn't do a full c2p. It only does it half way by converting 160x100 chunky to 320x100 planar with 4 chunky pixels being expanded to 4 times 2 pixels. Thereby only having to do half as many conversions.

At least that is how I imagine what it does.

If that is true then Akiko conversion needs to be twice as fast to be better overall

Agreed, Grind's C2P is already very fast as it is. Besides, Grind's chunky pixel layout is non-standard and I don't think Akiko can directly convert this layout. So, additional CPU cycles would be needed to convert Grind's chunky pixels into something Akiko can handle making it (how much?) slower.

[paraj]

Originally Posted by Mathesar

Agreed, Grind's C2P is already very fast as it is. Besides, Grind's chunky pixel layout is non-standard and I don't think Akiko can directly convert this layout. So, additional CPU cycles would be needed to convert Grind's chunky pixels into something Akiko can handle making it (how much?) slower.

Probably better to continue this (interesting) discussion in the other active Akiko thread (https://eab.abime.net/showthread.php?p=1690469), but I'll just note that the engine uses a few blitter passes (https://github.com/Krzysiek-K/Dread-...a_framework.s/) for C2P (in addition to massaged layout, can't find KK's exact post right now), so Akiko would never be plug and play anyway, though I suspect it could bring a performance improvement, but not without development effort that would currently be better spent elsewhere (just my 2c).