Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(1 edit)

Just a couple comments: 

3. One button joysticks.- This is highly appreciated; in all honesty I don’t own any more modern joysticks or joypads (I still use my old TAC-2 / Slik-Stik Suncom controllers from back in the day), so this is a must for some of us which haven’t upgraded our controllers / joysticks so far. 

1 & 5.- Separate builds, performance improvements & optimizations.- I’ve been playing this on a couple big box Amigas (2 A4000s). One has a BFG9060 accelerator with accelerator RAM built-in, that one is a beast, and the other is equipped with an A3660 processor board, no accelerator RAM, and only the motherboard FastRAM (16MB). On the BFG-powered A4000 everything is silky smooth as usual; on the A3660 powered A4000, I do see performance improvements over the earlier 0.90 version using the 040+ build. I see subtle, but tangible, improvements that make it way more enjoyable on that system.  Now it feels more fluid and somehow with slightly faster framerate, I don’t know if this is accurate, as I have no means to measure it, but it feels way better than before. QQ.- Is there a way to enable some developer mode that may allow to have some FPS measurements?

Amazing work from Reassembler and the testing team. Kudos for such a fine release! This is what I’ve dreamed for my Amigas many years ago... Thank you so much! :-)

Thanks for the feedback. I can provide development builds in future with better stats if you're interested in helping measure performance improvements on real hardware. It might make sense to setup a Discord group to do this. 

I tend to remove the granular measurements from the release builds themselves, as the extra code probably adds a bit of bloat/speed loss in itself. 

The 040 build uses a faster C2P algorithm for that architecture and some limited use of the 040 move16 instruction to move data about in the codebase. 

I reworked some of the original sub/road CPU code to be more register efficient with less reliance on memory access. I also changed the road rendering to minimise drawing of the secondary road layer (at the expense of a small amount of additional computation elsewhere). I also found a dumb bug where during certain situations I was clearing parts of the screen that didn't need to be.

I hope that provides a bit more background info!

Hi Chris. Yes! I’d love to measure performance in some of my systems, please let us know if you setup a Discord group for that specifically. 

On the other hand as you said , sampling processes takes up CPU and resources for sure, which it adds some bloat too, and also adds for some decreased performance. I was just way too curious comparing the earlier and the newer build. 

Thanks for the little explanation on  the C2P (Chunky-2-Planar) conversion algorithm, and how things work under the hood. It is always interesting to see and understand better how things work in the background.  On the foreground, it is amazing to see way better performance on my A4000 - A3660-based system (‘060 @50MHz, no accelerator FastRAM), which is more constrained by the slower RAM transfers using motherboard RAM which translates now, with these optimizations, on an overall better experience. It’s great! — Thanks again.  

 

I'd just join the Discord. I'll usually holler before a release if there's something to be tested - the traffic levels in there aren't too high:
https://discord.gg/u94mmuCzgB :)