• Please review our updated Terms and Rules here

Maker4D the RPG Game Maker Engine

two of my previous reply lost to the portal engine and i am lazy to retype them because they was very long, they contained benchmark results from the last update, they contained updates on the engine, and so on. so i summarize up within a few lines. trixter: i optimize this engine only to get overall speed-up in every platform, due to this i was already able to speed-up the code so now its playable on android phones and such. but doing specific optimizations for pentium1 in 2019 will not happen, (its just as a bad idea like when people use some shoddy hardware accelerated shader convention which will not existist within 3 year, just that would be the opposite end of bad decisions). profiling is only possible for script-languages where a line of code is 100 clock cycle, but not for c which compiles real code due to heay superscalar design and caching.

for gigabite, i typed some very long toughts for you for your previous reply, but i forgot what it was. yes, sdl is a bloatware, and i dont use it. (i use it on android, because i was lazy to learn android api, but not on windows or linux, there i only use os-based apis to interact with the system). btw you was right, cyrix wasnt able to boot the -586 kernel, and k5 also failed to boot it, so 6x86L is more close to 486 than to pentium.
 
April 24th: "I have decided to optimize this game engine to be able to run on 486's, P1 class computers."
May 3rd: "i optimize this engine only to get overall speed-up in every platform", "doing specific optimizations for pentium1 in 2019 will not happen"

Time to end this discussion?
 
That's what I find baffling here. Not optimizing for obsolete systems is a valid choice, but making that choice while also claiming that you're trying to support those systems is fantasy.
 
You could write an engine to support 20 year old hardware, but you'd have to limit any features you want to work on the least common denominator, the 20 year old hardware.

You could modularize the renderer like the Half-Life engine, so you'd have several rendering paths (Software, OpenGL, Direct3D and Glide) if you wanted more modern machines to have better detail and such, but that's a lot of extra work.

Though I'm not really sure what the OP is trying to do, as they're waffling around.
 
commodorejohn said:
That's what I find baffling here. Not optimizing for obsolete systems is a valid choice, but making that choice while also claiming that you're trying to support those systems is fantasy.
Click to expand...

i think It works so far as i was able to pump to 2fps (cyrix 250) so im slowly converging the speed to sort of playable frame rates.
its actually already sort of playable with stronger socket7 cpu-s so i already succeeded with this strategy just with a few good algorithmic optimizations.

GiGaBiTe: i would like to stuck with software rendering althrough with hardware rendering this would run about 10 fps which probably not worths destroying the simplicity of the code.

and here is new ideas i came up:
Half down the resolution of the 3D rendering
I canceled this idea after measuring the fps in smaller window with smaller resolution. It turns out that decreasing the resolution does not gives any notable boost (50% resolution decrease results 30% speed boost) which indicates i must work on other bottlenecks instead (such as the ones in the vertex processing), and keep the current resolution.

Optimizing the vertex processing
I decided to optimize the code in the renderer that calculates with the vertices. I was able to remove some dupicated code, removed some divisions but this only gave me an additional 2% speed-up which i ruled unsignificant
 
Are you doing hidden surface removal, or rendering everything? You shouldn't be rendering polygons the viewport can't see from its current viewing angle.
 
GiGaBiTe said:
Are you doing hidden surface removal, or rendering everything? You shouldn't be rendering polygons the viewport can't see from its current viewing angle.
Click to expand...

i cull objects beyond camera. however, there is almost nothing to cull in this practicular engine.

the engine does not supports normals so backface culling is not possible.

btw i discovered a bug today that resulted reloading a file from the disk in every frame. that have probably meant another 0.01 fps.
 
more updates:

1. i made the animation of far-away characters to skip a frame, allowing a small 10% speed increase.

2. i changed my mind and added the resolution halving - if the fps goes below 6, the resolution is divided by 2 on the y coordinate, halving down the rendering resolution. when the fps goes above 12, it restores the normal operation. this will probably give a 30-35% speed increase.

With the help of the last 3 update, the engine will probably run bethwen 3 and 4 fps on the Cyrix. This would mean the middle-class socket7 platform to reach sort of playable frame rates. i will measure it soon.
 
2019, may 5.
-Fixed a bug causing GDI overallocation and crash under older versions of Windows.
-The animation system now runs loosely on objects far away, resulting an extra 10% performance.
-If FPS falls below 7, the engine halfs down the 3D rendering resolution.
-The engine is now runs sort of fluid even on stronger Pentium1 computers and older Android 4 based phones.

Maker4D optimization for 5x86 class computers is finished for now.
The engine became sort of playable on Socket7 CPU-s fater than 200 MHz, including Cyrix, AMD and Intel cpu-s.

https://streamable.com/1yk3w

Updated download packages are updated on the site, enjoy.
http://maker4d.uw.hu/index.html
 
Geri said:
8000 where i measure it, but depending on the map it can be about 4000 to 20000
Click to expand...

That's far too many for how basic the scene is in your screenshots. I'd suggest working on adding hidden surface removal and simplifying both character and world geometry.
 
each character is 3500-ish polygon, shadow is about half of it (1750) i dont know if i could bring this down even more. the algo that generates these characters simplifies the geometry where it can in a postprocess pass, i dont know if could optimize this even more, althrough if i could, that would give additional boost. but good idea, i will check the code, maybe my mesh optimization lacks some trivial cases
 
almos.jpg

Lets see whats up.
I didnt optimized anything in the graphics engine since the last posts.
Ok, well, i did tried a few things, but didnt improved the speed so i wasnt come up with anything that i coud kept in the code.

However, i had a chance to compare Maker4D to Final Fantasy 7 battle system, approximately under the same circumistances.
Final Fantasy 7 battle system is prety much similar to this, enemy number can vary, have same menu system and healthbars, etc.
As Final Fantasy 7 supports software rendering, it was an obvious test to do.

I used the same Cyrix 6x86MX 250MHz config to compare the speed.

Final Fantasy 7 battle demo was around 0.5 fps, and in comparison, Maker4D battle system was able to push frame rates above 1 fps.

I am very suprised by this fact, as Final Fantasy 7 is from like 1997 so i assumed they have optimized the renderer for this class of comptuers much much better. (Or maybe it just uses FPU very agressively, thats why its so crappy on the Cyrix, compared to mine which does not uses fpu that much)

I was also tested the Maker on a VIA 666mhz C3 cpu too, and it was totally playable, very quick teleportation bethwen scenes,
 
I am proud to annouce the release of ARM V5 and ARM V7 ports of Maker4D (for Linux).
There is no performance upgrade for now, only some minor bugfix and the release for this two new platforms.

2019, oct 20.
-ARM v5 and ARM v7 ports for Linux has been finished.
-The engine now should work on Raspberry PI microcomputers, and on Wondermedia smartbooks too.
-Fixed a rendering glitch with 16 bpp display modes on Linux.
-Fixed a rendering bug with non-standard frame buffer bitmasks on Linux.
 
I made one last update in this year.

2019, dec 23.
-Fixed a crash bug with 64 bit binaries when resizing the window in doublescan mode
-Better culling algorithm to filter non-visible objects
-The rendering skips an automatic screen cleaning if its possible, which results more frame per second
-Small bugfixes in the 2D to 3D algorithm
-Battle camera does not stops when pressing escape
-Fixed a bug that caused text corruption on some systems


The last update did minimal improvement on the performance, when there is only one character on the screen, the fps reaches 3.8 (Cyrix 6x86MX 250 mhz).
 
I was able to come up with various new optimization for the animation code, that can cache more calculations of the bone code. One of these calculations can cache some lookup data bethwen frames as well. Depending on the scene, this will consume about half mbyte extra ram, which is unsignificant. This eradicates a lot of floating-point-heavy calculations, and it also gave a significant boost for the speed of the animation code (now that piece of code is more than 2x faster), overally it gave me a good 20% boost on a modern computer, i hope it will also give a good boost on Cyrix, althrough the boost will be probably not more than 20% even with a weak fpu, as this method will dirts a lot of cache.
 
The only real way to boost performance on a Cyrix is to not use the FPU. there were 3D engines made only using integer math, and they ran far better on a Cyrix than an Intel CPU, because the Cyrix was more efficient in integer math.
 
You must log in or register to reply here.
Back
Top