-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0|367|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> Language Tests -> ASM/GDI Sprite Test

Wed, 11 Oct 2023, 18:57

Please Test Sprite Code

This is a compiled 48KB EXE (25KB ZIP). It is 9+ year old code, just tweaked and recompiled and it should run on any Windows system, but does need a monitor capable of a 1200x800 window. This is using GDI for displaying and ASM for blitting. Please let me know what FPS you get at each stage. The second to last stage is 100,000 tiny sprites. It would also be helpful to know what processor you are using and speed. This does need a processor capable of threads, whether virtual or actual cores.

Would also be curious as how it does for Jay on his emulation on Apple Silicon.

2023/41/SOCODER_SPRITE_TEST (.zip)

Thank you in advance. This will only go up to 100,000 sprites, but I have tested it on my system with 500,000 sprites and it only drops the FPS by about half. No known bugs, but like I said this is 9+ year old code and with all of the stuff I have been through, it is hard to get into the headspace from that long ago. But, this seems very stable. I have been letting it run at the second to last stage for well over an hour, no crash or memory leaks.
Wed, 11 Oct 2023, 23:33
Managed a solid 30fps on all tests, in virtual Win11, using UTM on the MacM1.
30fps is likely due to the render speed of the virtual machine, as I haven't got anything over 30fps out of it.

''Load, Next List!''
Wed, 11 Oct 2023, 23:43
Thanks. Damn, That's better than what I get. Tomorrow when I have time, I will post a 500,000 sprite compile just for you to test to satisfy my curiosity. I am guessing you may get around 20-22 FPS with 500,000 sprites.
Thu, 12 Oct 2023, 11:32
I sent you a PM with a version that does 500,000 sprites on the second to last stage. Keeping that one just for you as I am just curious what FPS you will get on your system that is kicking ass under emulation, and emulating X86 on an ARM device and still pulling off the highest FPS.

I would be curious if folks with normal Windows systems could test the first one and report their FPS. Thank you in advance.
Thu, 12 Oct 2023, 12:06
i7 6th gen 4.00GHz
16gb RAM
Windows 10 Home

Check out my excellent homepage!
Thu, 12 Oct 2023, 12:09
The zip from the first post does around 25 fps on every scene until it closes. This on the Ryzen 5000 and radeon lenovo laptop.

Windows does give those warning screens in advance
Thu, 12 Oct 2023, 12:42
I'll test the heftier test tomorrow, if I manage to wake up.
Had the Covid jab, today, and feel absolutely dead, right now, but still have an ALChoon to finish off, but think I'm about to zonk out!!!

''Load, Next List!''
Thu, 12 Oct 2023, 17:49
Roughly 8 or so fps once the mega-test gets going.

But again, remember that that's running in UTM, without any acceleration, so that's really quite good.
Worryingly, it's refusing to run using Crossover, which is "usually" the more compatible of the two virtualisation engines. Crossover DOES do graphics acceleration, so. ....? Quite what that says, I'm not sure.

It might struggle once you "properly" start making use of the engine, though. That what I've found over the years. That there's a vast difference between what a stress test can do, and what happens once you're actually doing things behind the scenes.
Maybe add a couple of lines of "stress=Rand(100)/Rand(5,100)*Rand(6)+Rand(100)" inside your loop, so you can see a more realistic figure, once you start properly interacting with the gameplay, collisions, logic and such.

In general I aim for about a quarter of what I presume an engine's stress test is capable of.

Usually the bottleneck for me is my haphazard code style, and lack of optimisation, not the actual drawing code.
Which makes it all the more fun when I spend days and days squeezing every ounce of speed out of JSE that I can!! I rarely ever do that sort of thing.

''Load, Next List!''
Thu, 12 Oct 2023, 20:05
Thank you Jay. Very appreciated when I know you are not feeling well. 8 FPS? Wow, I beat that, I get 12 FPS on a AMD Ryzen 5 3500U. Surprising. Very interesting. Nice to know the compatibility is there when running on a M1. I only did the 500,000 sprites to see what you would get, since the other beat mine which is 25FPS.

Crossover... I used to be an "advocate" and could use it for free in exchange for reporting my experiences back to them, they changed that so I talked to them a month or so back asking them if it would run on ARM Chromebooks, and they said no, only on X86/X64 Chromebooks. I was told it could not emulate the X86 well on an ARM. I do not know, as that is above my paygrade.

That said, my code does NOT use the GPU in any way, it is strictly GDI (which I guess on modern versions of Windows does use the GPU for desktop compositing), but it is still slow as can be, because GDI uses a software BLIT. My code is double-buffered but uses custom ASM routines to do the BLIT, which I am going to argue IS a hardware BLIT since I am using the CPU to do it.

The example is mainly to test the speed of the BLIT, and numerous sprites merely gives it more to BLIT.

In general I aim for about a quarter of what I presume an engine's stress test is capable of.
This is a good rule of thumb and one I will try and remember and go by.

Like you say, logic and everything else is the real bottleneck, although there is collision going on in that example, it is just detected and not acted upon.

I generally do not make games with a lot of moving sprites. Certainly nothing ever approaching the 100,000 in the first example. 1,000 sprites may be possible in a game if I am using GUI elements and such as sprites, but actual moving sprites would never be more than 100 in most anything I would do.

Main issue for me is that code is all 32bit. I am strongly considering moving to 64bit only, which means I would need to rewrite the ASM or abandon this code. That said no real need for 64bit, but regardless I am not going to support anything older than Windows 10.

Happy to hear thoughts on 32bit vs 64bit?

Big thank you to everybody for helping test. Seems to be reliable routines working properly on Intel or AMD and even under some emulation.
Fri, 13 Oct 2023, 02:54
About 25 fps here (+- 0.2fps)

on : "Intel® Core(TM) i7-4790 CPU @ 3.60GHz 3.60 GHz"
64bit win 10
Fri, 13 Oct 2023, 17:17
25FPS on my rig:

* i7-7700K CPU @ 4.20GHz 4.20 GHz
* 32 GB
* GTX 1080
* Win 10 64bit
Sun, 15 Oct 2023, 22:13
Thanks guys.
Fri, 27 Oct 2023, 21:40
Well, this was short-lived. Programming language has an odd quirk with Windows 11 and programs written will not close in some instances depending on how it closes. At least I know the ASM routines are still solid thanks to everybody who tested.