61 replies to this topic

[Pickle]

Would an updated screeny make sense ?

Not really cause the powerups are just using pyramids for the model, so it all looks redundant. in a static screen. I think a video or alpha release might be soon, at least thats what im aiming for.

[kayuz]

great! i hope in a alpha for caanoo too

[Pickle]

great! i hope in a alpha for caanoo too

It will be ES compat, i actually built a wiz version, but just havnt had time to debug what is wrong. If there is no SDL for caanoo with opengl support I may have to take more time to code up a raw egl with raw controls for caanoo.

[sebt3]

It will be ES compat, i actually built a wiz version, but just havnt had time to debug what is wrong. If there is no SDL for caanoo with opengl support I may have to take more time to code up a raw egl with raw controls for caanoo.

You can found a eglport.[c|h] working on caanoo in caanmines sources

[Pickle]

It will be ES compat, i actually built a wiz version, but just havnt had time to debug what is wrong. If there is no SDL for caanoo with opengl support I may have to take more time to code up a raw egl with raw controls for caanoo.

You can found a eglport.[c|h] working on caanoo in caanmines sources

That part wouldnt be bad as i already have the sdl eglport, its isolating all the SDL calls into generic ones.

[kayuz]

... i hope, anyway, to try your game on the only open console i have

[Pickle]

Added material support (which breaks my curreent shader renderer). This lets me assign any material or texture per group in the obj format. So for example I could now specify different lighting and texture parameters for each side of a cube. The bad thing is that for the shader path I have to now switch between shaders per this groups. Before I had assumed the model was either all color or all texture. For now though im going forward and when things have progressed I will go back and fix the shaders.

Ive also started the object path functions. Right now I have 2 options a straight linear movement from one point to another. The second is a curve defined by degress, radius, and divisions.
I think the way im going to do with linear is to subtract the 2 points to get a direction vector. I will calculate the magnitude the vector and divide the speed constant by the magnitude. Then i can use the resulting ratio on each component of the vector for my final speed to apply to the current position. If anyone has a better way let me know.

For the curved i use the radius to define the size of the circle, the degrees defines the length of the curve. The divisions is how many linear paths to break the curve down into. So by breaking the curve down into a bunch of linear movements I can use the linear travel I described above. Right now the curve is assumed to be on the x-z plane.

Update: Linear motion is working ;-)

Update 2: I worked some more on paths and ive just about got it. Changed the way i go about it a bit. The config file values are read as offsets from the current position. The curves are split down into lines, but its done at loading rather than at runtime. So the final path is just a bunch of way points. In my last test I did get a 90 deg curve, but in the wrong direction and it looked a bit big. So i think i little more debug and testing on the curves and it will be good.

[Pickle]

Made some good changes and updates over the weekend.

Materials (obj/mtl) works, this means i can have a infinite number of lighting materials defined by file and then i can specify them in the obj models. For example the test i did was to specify a material for each side of a cube.

Paths work now, they work by defining a starting point, linear travel offsets from the last point, and curves defined by plane, radius, angle, segments (which break down into linear travels)

The Font.obj is done! I have a alphanumeric characters rendering. I may need to add a few others here and there. But its nice to see the score changing now :-)

I added an option to the wave config files to specify count, time offset, final position offset for a single monster entry. This mean i can have one line to make a group of monsters that come out on the same path. Once they reach the end of the path they will line up according to the offset defined. Before I was specifying each one per line.

With the last test I did some tests with 60 monsters and it started to bring the performance down on my x1400 radeon linux driver to ~30 fps. Pandora is hitting 20 fps. I may need to keep groups small and trigger new groups based on if earlier waves have been eliminated.
There are also are probably bottlenecks which I just have done with this being my first real opengl engine.

Also since I ran it on the pandora the gles1 code is "error" free. GLES2 is still broke when materials were added.
The GLES1 on pandora has some oddities yet. The intro screen sometimes blacks out on the right hand side. Not sure if this a depth or lighting problem.

All in all a good step and and much closer to having a test alpha ready.

[kayuz]

Good to hear this, Pickle
if you need tester, for a caanoo version, i'm here

[sebt3]

All in all a good step and and much closer to having a test alpha ready.

Nice I'm looking forward reading your code

[Pickle]

Worked on a shader program manager that I hope can switch between programs as needed, but it doesnt render anything at the moment.

Also been thinking about the way I currently do rendering I realized I have a hug amount of redundant opengl code. Right now I render each model by instance, so for each instance I will bind buffer, set attrib pointers, render arrays. I need to change this that i render by model updating the modelview per instance.
By making this change for each model I bind and setup data arrays only once per loop.

I also need to add some enhancements to grouping specifically to textures. Right now I may have for a cube 8 different drawarrays because the obj defined 8 groups for each side. I think I should be able to do the entire cube in one drawarray (if the texture is the same)

Also I did some testing and the bad fps on the pc side was because of the frame limit code I had, with it disabled the game runs at 60 fps. Basically if any vsync is used then it could mess with my frame limit.

[Pickle]

Another decent weekend of dev'ing.

The shader rendering is finally debugged and back to the state it was before i added material color support (although the shaders themselves dont handle this lighting method yet). Also on top of it the shader path works on the pandora :-). I added EGL ES 2.0 bits and I needed some precision statement for my shaders (dont understand this quite yet). I may need to add a way to handle defines in the shaders, as the precision statement doesnt compile on desktop opengl.

I also added the single binding of the vbo and vertex pointers, not sure if it helps or not. Cant be bad to call opengl less times. This change also drove some other changes in the level/wave configuration, but they are good changes as they give more flexibility.

I tried again to run on the wiz using the ikari sdl with opengl support. For whatever reason I get opengl not supported. Seems like it isnt using the right SDL lib, even though I used LD_PRELOAD to override. Might just have to go RAW egl/controls without SDL. Might need this anyway for the caanoo.

Pandora is getting 30 fps with both ES paths. So the real fps is between 30-60 since vsync is being used. But I havnt really dived into detailed optimizing. For example i know im recalcilating some matrix operations every loop, which is wasteful.

I have some bugs left to kill, somehow im getting a vector out of range after some of the single vbo bind changes. Not sure yet how that is happening. This happens on all platforms.
The pandora still has some odd issues to work out.
One problem I have left is how to handle line size on the shader side.
Also i broke my points in the font as the indices are getting combined but the point indices are not being updated.

[kayuz]

good to hear progress.
i know that the caanoo support OPEN GL ES 1.1.. so your game is in what library?

[Pickle]

Ive written it to support both ES 1.1/2.0. GLES API is a subset of the normal API. When i build a desktop version it can run either path at runtime. For the handheld devices I can compile with either ES 1.1 or ES 2.0 support.

[kayuz]

fantastic! this can run on caanoo... but i don't think fast as the pandora