[PROJECT] ProTracker v2.3D clone for modern platforms

[tolkien]

I have modified the palette and this is the result.




EDIT: trying differents values seems the format is BGRA. Now looks much better.

[8bitbubsy]

I modified the code and some tables now to make the program fully compliant with what pixel format is used by the target system (only in the normal non-OpenGL version).
Do an "svn checkout" again. Might make a conflict, better backup changes you did to diskop/helpers.c, then wipe folder and checkout, then copy changes over to the files. Let me know if it works...

Now Disk Op. and the realpath() stuff remains. Will look into that when I have more time.

[tolkien]

Hey! Now It looks great! Good work mate. Good work!

[tolkien]

I have testing It and I see that the CPU goes to 90% even with protracker stopped and without a mod loaded. Will see the main loop tomorrow.

[Dunny]

that might be SDL - I had that issue in one of my projects a while ago whilst using event waiting; SDL sits in a tight loop consuming 100% CPU time waiting for an event. Not nice.

D.

[8bitbubsy]

No, it's not SDL, it's probably because I'm blitting a lot of 32-bit data 60 times a second, then I upscale it to 2x in software mode (also 60 times a second). I'm not blitting data only when it needs to be updated, I blit it all the time on top of eachother every frame. It doesn't even take 1% CPU on my Core i7-950 3GHz, but I guess there's not a single machine in the world running MorphOS locally with such a CPU. :P
I properly sleep when needed in the main loop so that the timeline is somewhat synced to 60Hz and so that it doesn't eat up all the CPU time.

Btw, the OpenGL version takes up more CPU time (ironically), but it also has a more stable 60Hz fps on modern GPUs (and it supports fullscreen mode - F11).
tolkien: Try to replace pt_main.c with this as a test to see how much CPU percentage it uses when rendering is disabled (no picture, just upscaling left): http://pastebin.com/CCssKPQ9

[Dunny]

Ahh, yes. I also blit (though at 50fps) a full screen display, but obviously not on one of those CPUs

D.

[8bitbubsy]

I'm in the process of rewriting the whole thing so that things are only blit when it needs to be updated. I already made the mouse pointer replace the background behind it when it moves, and started from scratch to make some update flags for status texts, ask dialogs etc... This will take a long time, but when it's done, it should be extremely fast, the only slow thing left then is the 2x screen blit routine and the audio mixer.

[Bastich]

Under DX or OGL rendering the whole screen every frame isn't an issue. Unless your hardware is as old as an Amiga Software rendering should be avoided at all costs.

[Dunny]

Originally Posted by Bastich

Software rendering should be avoided at all costs.

Why do you say that? What's wrong with software rendering?

D.

[Bastich]

Its very slow and can hog the CPU. The amount of data send to the GPU per frame should be minimized. In modern games etc in order to render a model all that is passed to the GPU is a matrix or 2 not every vertex and texture. Correct usage of GPU ram can speed rendering up massively. Hardware acceleration FTW.

Its what made the Amiga great to start with

[Dunny]

Yeah, but in the context of a protracker remake hardware acceleration makes little sense. I mean, if all you're doing is displaying a 640x480 bitmap 60 times a second then it's going to take just as long to upload it to the gfx hardware as it is to blit it to the window surface.

D.

[Bastich]

You would only upload the textures to the graphics card / GPU VRAM once and then its just a reference and coords that is passed (very few bytes) which is insanely faster than passing a texture across the bus each frame.

The only part that probably should be done in software is the oscilloscope and even that could be done using point spirites or in a pixel shader.

Great project runs full speed on my system

[tolkien]

Olav:
I have tried the new main. The CPU gets a bit lower but still high. Around 83% of cpu usage instead of the 90% with the original one.
Mates! My poor G4 need a few cycle saving!

[Dunny]

Originally Posted by Bastich

You would only upload the textures to the graphics card / GPU VRAM once and then its just a reference and coords that is passed (very few bytes) which is insanely faster than passing a texture across the bus each frame.

The only part that probably should be done in software is the oscilloscope and even that could be done using point spirites or in a pixel shader.

Well, yes, for this project - but the rule "you should never use software rendering ever" is not true for all programs. My own tracks changes to the frame buffer as far as is possible, but as changes are impossible to predict it's actually faster to draw the buffer in software than it is to implement in hardware.

I know, I've tried it.

D.

[Bastich]

You didn't quite quote me accurately there. What I actually said was "software rendering should be avoided at all costs" not "you should never use software rendering ever".

Out of interest thou which bit would be faster in software?

[8bitbubsy]

I'm far in the new rewritten version that only blits data when it needs to be updated. A lot had to be changed, the only thing left is a couple of dialogs and some throughout testing of the whole tracker.
This version will actually be very close to the Amiga PT code. I even wrote a sprite engine that at the end of the frame render sprite objects from a list, then when the framebuffer is flipped, it erases them from the framebuffer again. Used for mouse pointer, loop points (sampler), sample play position line (sampler) and pattern cursor. This way I don't need to clear the screen every frame, and I use setSpritePos() just like in the original PT code.
This new version is not online yet, so the one on SVN is still the old one.

Anyways, the real CPU killer is the upscale function and apparently SDL_Flip().
SDL_Flip() on Windows seems to copy the surface pixels to the *real* framebuffer instead of just flipping, because in an SDL program with a big resolution and nothing more than sleep()+SDL_Flip(), it still takes quite some CPU time on my old Pentium M 2.0GHz laptop...

[tolkien]

Cool mate. I'm here if you need some testing.

[8bitbubsy]

The new optimized version is up at http://16-bits.org/pt.php and the SVN repository is updated.
This will probably not be faster on your system since the framebuffer flipping and upscaler is the CPU killer, as mentioned before, but it sure is faster in OpenGL mode for slower systems that still supports the ARB pixel buffer stuff. Much faster on my older Macs.

[tolkien]

Has SDL2 better performance than SDL? Is much different to try It with SDL2?
I'm only thinking
Will try your new version this weekend.
Thanks mate.