Tinyus Tech

[pink^abyss]

Originally Posted by zero

It feels like this is one of the most important parts of the code, the reason why you are able to get so much on screen. The blitter can do so much if handled right, but I don't think many games came close to this level of performance.

Interesting! How are you managing allocations? A lot of games just used arrays, but of course then every object has to be fixed size.

Yes, to have optimal performance its just arrays for everything. There is no dynamic memory allocation going on at all. To handle the different data within a class of objects i use unamed unions. So i can easily 'compose' new behaviors for my objects that share something common. Of course you waste some bytes with this approach but usually your number of objects is quite small (something between 16-64 in my cases). And each struct themself is usually only a few bytes.

[zero]

Originally Posted by pink^abyss

Yes, to have optimal performance its just arrays for everything. There is no dynamic memory allocation going on at all. To handle the different data within a class of objects i use unamed unions. So i can easily 'compose' new behaviors for my objects that share something common. Of course you waste some bytes with this approach but usually your number of objects is quite small (something between 16-64 in my cases). And each struct themself is usually only a few bytes.

That's how I do it too, although not in games, on embedded systems.

Usually trade memory for performance, 16 bit alignment etc... But I wonder how that works out on the Amiga? Maybe two memory reads is less efficient than one memory read and a swap. Oh, but it's C, so maybe you aren't optimizing to that level anyway.

[pink^abyss]

Originally Posted by zero

That's how I do it too, although not in games, on embedded systems.

Usually trade memory for performance, 16 bit alignment etc... But I wonder how that works out on the Amiga? Maybe two memory reads is less efficient than one memory read and a swap. Oh, but it's C, so maybe you aren't optimizing to that level anyway.

On Amiga 500 i try to make everything optimal from the start to have enough performance in the end. So i care about memory layout, and what types i use. However, in my experience it doesn't matter much if you use C or ASM with game development if you only consider performance. GCC 10 is good in optimizing.

[roondar]

I've been quite surprised with just how good GCC 10 is at optimising. I did a few minor tests in Bartman's Visual Studio Code environment and the assembly it creates is quite good.

[jotd]

so basically you didn't use the original code as you thought you could write more efficient code from scratch.

And that worked.

[malko]

Originally Posted by jotd

so basically you didn't use the original code as you thought you could write more efficient code from scratch.

And that worked.

considering the differences between the arcade board and the amiga, this is a logical choice

[jotd]

I'm also interested by this gcc 10 version.

I've used bebbo's gcc 6 for my game (Bagman) and (no offence) I'm disappointed by the speed. Maybe it's me, maybe it's C++, but in my game nothing much is happening and I find that slow...

I've used the blitter, avoided memory copies and all, not a lot of characters, no massive blits, no scrolling, using 16 colors, and still the game is super slow... it needs a 68030 IIRC.

[lmimmfn]

Originally Posted by pink^abyss

On Amiga 500 i try to make everything optimal from the start to have enough performance in the end. So i care about memory layout, and what types i use. However, in my experience it doesn't matter much if you use C or ASM with game development if you only consider performance. GCC 10 is good in optimizing.

I might be wrong but didnt you mention vs arcade its only doing collision detection every second frame?

[Bartman]

Originally Posted by jotd

I'm also interested by this gcc 10 version.

I've used bebbo's gcc 6 for my game (Bagman) and (no offence) I'm disappointed by the speed. Maybe it's me, maybe it's C++, but in my game nothing much is happening and I find that slow...

Yeah, we found each major version update gives 10-20% extra performance

[zero]

Surprising how good GCC is for 68k. I didn't think 68k got much love which usually means poor optimization.

[pink^abyss]

Originally Posted by jotd

I'm also interested by this gcc 10 version.

I've used bebbo's gcc 6 for my game (Bagman) and (no offence) I'm disappointed by the speed. Maybe it's me, maybe it's C++, but in my game nothing much is happening and I find that slow...

I've used the blitter, avoided memory copies and all, not a lot of characters, no massive blits, no scrolling, using 16 colors, and still the game is super slow... it needs a 68030 IIRC.

I looked through your code on GitHub and saw you use SDL. I don't know the SDL port for Amiga but i guess this is the main issue why your game runs slow. The other parts of your code look mostly fine for Amiga 500 (at least when LTO is enabled because you have a lot of function calls). If you really want to know where the performance goes then you need to profile

[pink^abyss]

Originally Posted by jotd

so basically you didn't use the original code as you thought you could write more efficient code from scratch.

And that worked.

Yes, the arcade code would have been be too slow on A500.

[jotd]

@pink^abyss

Thanks for checking my code No the code doesn't use SDL (amiga SDL uses chunky2pixel so it's a no go from the start!)

It uses SDL interfaces, but the structures have been hacked to use the blitter. Images are loaded as planar, and SDL_UpperBlit performs... blits .

It's a port from a SDL game, and I thought that it would be easier not to remove the SDL interface. It was kind of a challenge but it worked.

Basically the assets are pngs for the SDL windows version, but a python script combines them to compute the best 16 color palette then creates custom format with header + bitplanes compatible for the blitter (and sprites, but that's not active yet). I'm pretty happy with that engine, except for the speed... Using ptreplay from phx was also very easy.

Now if you have the link for a GCC 10 for 68k compiled for windows, I'd like to rebuild with that. I'd like to avoid VSCode if possible, I already have a project under a different build system.

Profiling is always a good idea. I didn't get how it can be done on amiga though... I hope the C++ part isn't the main culprit as it would be a pain to rewrite all that in C.

So if you have some more details/links I'll happily check them. If I had to do another game, I'd probably avoid the multi-platform part that time...

found this https://github.com/BartmanAbyss/vscode-amiga-debug seems to contain everything that looks great

[pink^abyss]

Originally Posted by jotd

@pink^abyss

Thanks for checking my code No the code doesn't use SDL (amiga SDL uses chunky2pixel so it's a no go from the start!)

It uses SDL interfaces, but the structures have been hacked to use the blitter. Images are loaded as planar, and SDL_UpperBlit performs... blits .

It's a port from a SDL game, and I thought that it would be easier not to remove the SDL interface. It was kind of a challenge but it worked.

Basically the assets are pngs for the SDL windows version, but a python script combines them to compute the best 16 color palette then creates custom format with header + bitplanes compatible for the blitter (and sprites, but that's not active yet). I'm pretty happy with that engine, except for the speed... Using ptreplay from phx was also very easy.

Now if you have the link for a GCC 10 for 68k compiled for windows, I'd like to rebuild with that. I'd like to avoid VSCode if possible, I already have a project under a different build system.

Profiling is always a good idea. I didn't get how it can be done on amiga though... I hope the C++ part isn't the main culprit as it would be a pain to rewrite all that in C.

So if you have some more details/links I'll happily check them. If I had to do another game, I'd probably avoid the multi-platform part that time...

found this https://github.com/BartmanAbyss/vscode-amiga-debug seems to contain everything that looks great

Ah, nice, i did't realize the amiga sdl emu you did!
It seems you are running while the OS is active? This takes away a lot of performance on A500. Also the non interleaved blits add a lot of overhead. The blit routine for objects <16 pixels will become super slow when it goes into the setpixel block. If you call it just one each frame it could eat all rastertime on A500. I'm not sure about the C++ overhead from older GCC. I currently use C++ for with Bartmans GCC10 (without any dynamic memory allocations). C++ is as fast as C for me so far.

[roondar]

AFAIK there was a point at which the GCC optimisations suddenly became much better on the M68K branch. Not sure if that was version 8, 9 or 10 but I remember seeing a video about Amiga demo coding in C that talked about this leap in performance.

[Bartman]

are you referring to my seminar? https://www.twitch.tv/videos/468413972?t=02h20m09s

Excerpt from there:
VBCC->GCC 6.2 +100% ->GCC 7.0 +20% ->GCC 8.2 +20%

[roondar]

Originally Posted by Bartman

are you referring to my seminar? https://www.twitch.tv/videos/468413972?t=02h20m09s

Excerpt from there:
VBCC->GCC 6.2 +100% ->GCC 7.0 +20% ->GCC 8.2 +20%

Yes, that's the video. Was extremely interesting, thanks for making it

[jotd]

problem is: I'm using a lot of standard library (C and C++) in my project. And the distro seems to provide bareboard includes only.

[pink^abyss]

Originally Posted by jotd

problem is: I'm using a lot of standard library (C and C++) in my project. And the distro seems to provide bareboard includes only.

Yeah, there is no standard support beside barebone stuff like memcpy and such. As Bartmans solution is targeted for A500 game and demo coding it doesn't made much sense to support the standard libs.
A few days ago i switched to C++ on A500 to enjoy much less typing then i had to do with C. Also having now ranged for loops in my templated UnitHeaps saved a lot casting around and adds some extra safety at compile time.

[jotd]

I now suddenly understand why your games are only made with 1 exec file.

All assets are probably "static const unsigned char bitmap[] = {0x...}" like. It makes sense, as long as the whole game data fits into memory without loading.