Pseudo-3d

jdbc

Hi all.

After reading a post about how to develop a classic OutRun game from http://codeincomplete.com/posts/2012/6/23/javascript_racer_v1_straight/, I have developed part of this code to Gideros / lua.

It works smoothly in Gideros Player but really slow in my Samsung Galaxy Ace. I guess main problem is that a simple port always redraws again all polygons of the road in every frame as actually sample javascript code does.

Better solution is to build an static set of array of polygons and change only color and textures.

Any suggestions or someone who had try similar issue? I attach my current testing Gideros project.

petec

It actually slows down with time in Gideros Player. You are adding the player to the stage in your update function, so a new player gets added each frame. Same with all the road segements. So I think it's getting stuufed up with children! Add the line

print(stage:getNumChildren())

to the end of your update function, just after you've add the player to the stage, and you'll see the number of children increase quite rapidly.
I think you'll need to manage things so that you are removing old children before adding new ones and maybe just adding the player once outside the update loop.

jdbc

It actually slows down with time in Gideros Player. You are adding the player to the stage in your update function, so a new player gets added each frame. Same with all the road segements. So I think it's getting stuufed up with children! Add the line

print(stage:getNumChildren())

to the end of your update function, just after you've add the player to the stage, and you'll see the number of children increase quite rapidly.
I think you'll need to manage things so that you are removing old children before adding new ones and maybe just adding the player once outside the update loop.

Yes I think you are right, my first try is creating a lot of children of stage ....

I will manage this, because original javascript code manages it for itself.

Thanks.

petec

You're welcome. Good luck with sorting it. It looks like it could be good fun. I remember one Christmas waiting for ages with my son while Outrun loaded on my Spectrum!

techdojo

I mentioned this site in June last year http://giderosmobile.com/forum/discussion/comment/8131#Comment_8131

Glad to see someone picked up on this. I had a "very" quick look at the code and noticed the slowdown straight away. I think your using shapes to draw the road segments, you should get a massive performance boost, if you just pre allocate a pool of shapes and then just reorder them instead of allocating a new bunch of shapes each frame - also you won't have to worry about removing the old ones.

Hope you managed to get the rest of the part's implemented as this could be a decent showcase for Gideros.

jdbc

I made a refactoring of the previous code (more OOP) and it seems the performance is not going slow down (new children and removing oldest).

Gideros Player works ok and Samsung is working but not really well. I guest I will need implement a segment cache with the previous created shapes and just changes colors.

Anyway you could try if this prototype works smoothly in other real mobile or tablet devices.

jdbc

I mentioned this site in June last year http://giderosmobile.com/forum/discussion/comment/8131#Comment_8131

Glad to see someone picked up on this. I had a "very" quick look at the code and noticed the slowdown straight away. I think your using shapes to draw the road segments, you should get a massive performance boost, if you just pre allocate a pool of shapes and then just reorder them instead of allocating a new bunch of shapes each frame - also you won't have to worry about removing the old ones.

Hope you managed to get the rest of the part's implemented as this could be a decent showcase for Gideros.

I have read your post of june. It provides me some inspiration !!!

jdbc

Hi again.

After some research about how to improve rendering performance of segments, I think it is not so easy as simple changes color, because about 60 segments are created on each frame, but projections are calculated again.

Anyway I am not sure if create a shape pool (lua shape table) will increase the performance so much, so Does any one know if creating objects consumes a lot of CPU time and if Gideros is optimized in this sense.

I know the best option is to create a rendering plugin in C++ but this will be reimplement part of Gideros, something I want to avoid.

I hope for suggestions. Thanks.

techdojo

You could do all the maths in C++ and have it generate a table of shape data which you just copy across for rendering.

OZApps

@jdbc, did you try the curves in the road for turns?

jdbc

@jdbc, did you try the curves in the road for turns?

I only develop the prototype, but it works really slow in some Android mobiles due the fact my Gideros port needs to create again segments (set of Shapes) on every onEnterFrame event. May be for Android mobiles and tablets with good CPUs and iOS, it will work nicely. It depends on segment numbers we need for slow mobiles.

I guess pseudo-3d is better use C++ native as SDL not Gideros indeed.

Anyway I will share my code in github of this prototype game, so Gideros community can improve it or brainstorming about this issue.

OZApps

@jdbc, it is strange that 8-bit computers (in my case ZX Spectrum) could draw these roads perfectly fine and at reasonable speeds, even if it was assembly, it was still a 8-bit computer running at about 3.5MHz) maybe there is an easier way.

Your effort is amazing and if others interested would try to optimize it, it could become something better.

SinisterSoft

Shaders will be able to do this. But you're right about it should be able to process this much data without slowing down.

ar2rsawseen

@jdbc is it possible to use Meshes instead of Shapes? It would also speed it up.

@OZApps, I have a filling you think you've missed a lot, trying to digging up all the old topics

OZApps

@ar2rsawseen, yep!! BTW you are giving a lot of material to Platypus for newer topics...

Filling is what you put inside a hollow, like the meat filling in a pie
what you meant was feeling which is an emotion.

Darn, I ended up with correcting you

ar2rsawseen

I just woke up, give me a break
I know the difference and understand it completely, just my hands sometimes type the wrong word, and I'm too busy with the content to notice it

jdbc

If someone wants to check the code, it is available here:

https://github.com/jdbc2012/race

jdbc

Now there are some left and right curves and some music in this prototype. Next it is to make parallax scrolling when curves appears.

I am thinking how to store a track information: it means store when curves, hills and z axis information, may be a simple lua table.

jdbc

@jdbc is it possible to use Meshes instead of Shapes? It would also speed it up.

@OZApps, I have a filling you think you've missed a lot, trying to digging up all the old topics

I have checked drawing a lot of segments using Shape class is the performance problem (of course, some maths could be also calculated on C++).

How do you suggest to use Mesh for drawing segments?
Is there a way to convert Shapes into Mesh?

ar2rsawseen

@jdbc Meshes can only represent triangles, so with some Triangulation algorithm you could convert Shapes to Meshes automatically, but I'd say it would be easier and maybe even faster to rewrite it manually.
Just provide vertices coordinates and fill them with colors as you did with Shapes.
The performance improvement should be significant.

jdbc

I have replaced Shape by Mesh in my code.

Anyway it is not enough for slow mobiles, but increases a lot the performance. I will try on Xcode for iOS.

ar2rsawseen

@jdbc yes you are right, right now I only get lags on the hills (because more segments needed there probably).

Next optimization I can think of is either:
1) use pooling, as in place used segments in pool and reuse them later when needed
2) (which I think should be even better, but is tricky) use only one single Mesh object for everything.

jdbc

@jdbc yes you are right, right now I only get lags on the hills (because more segments needed there probably).

Next optimization I can think of is either:
1) use pooling, as in place used segments in pool and reuse them later when needed
2) (which I think should be even better, but is tricky) use only one single Mesh object for everything.

Cool !

If everything was a mesh, there will be only one object to render !!!

I will try (2), replacing rectangle and polygon childs by vertices and index on the mesh.

jdbc

After some changes, now all segments are Mesh objects.

It seems performance are better, it could be a first approach to have a 2.5D engine. Of course for even better performance we could avoid segments do not belong to road, or have only a mesh to describe road + sides.

For math calculation, I guess we can use a C++ funcion providing a set of points and returning a set of points with the results.

ar2rsawseen

@jdbc do you have an experience with C? If you can get all the math in C, I can help by wrapping it in lua.

jdbc

@jdbc do you have an experience with C? If you can get all the math in C, I can help by wrapping it in lua.

Sure I have experience with C / C++.

I will try maths then.

jdbc

Here's a video of this prototype:

ar2rsawseen

Getting better and better.
So is it with C math already?

jdbc

Getting better and better.
So is it with C math already?

It is lua, but next will be lua binding :-)

I have been studying lmathlib.c from lua 5.1.4 source code.
My first try will be replace Utils.lua with a simple call using LUA C API, that is calculate screen coordinates from world ones. I will use cmake to compile for Windows.

jdbc

I have replaced Lua with LuaJIT and it seems to work much better.

I guess using LuaJIT + FFI we can make projection maths with native C, so basic 3D as my prototype can be done using Gideros + LuaJIT.

pie

Hi @jdbc, is this project still working for you on the current gideros release?
The file testffi.lua (declared in the gproj file) is missing, and removing it crashes the gideros windows player with a visual C runtime error