Author Topic: Joncom2000's attempt at Opengl (Read 32939 times)

TinDragon · « **on:** March 13, 2009 »

After seeing Zawrans progress on making an opengl engine and watching Shockwave's more recent intros which also use opengl I decided it might be a good way to get myself coding again by also having a go at making a simple opengl engine. After some chatting to Zawran and some messing around with bmax's types to get a feel for the way they work, which to be honest is very much like a c++ class in my view, I made a start on my engine attempt.

So I would like to present my 4th test, the engine itself handles some basic information about entities such as position and rotation but I havent full implemented the drawing side of the code in the engine so I am doing that outside the engine but hope to have that part going soon so everything will be drawn with a simple renderworld type command. It uses displaylists to store an entity's mesh, at the moment it has cube and plane primatives. Next I need to get lights in there but for an afternoons work I am happy

Pic and demo with erm bodged in texture support attached

zawran · « **Reply #1 on:** March 13, 2009 »

Works like a charm on my computer. And great to see you at the code again

matthew · « **Reply #2 on:** March 13, 2009 »

The image looks good but I can't get the demo to run here.

When I double-click the exe a window appears & then quickly disappears.

What screen resolution does the demo use because I know my graphics card doesn't like some.

zawran · « **Reply #3 on:** March 13, 2009 »

It runs in a window which looks like its 1024x768.

[edit] forgot to mention, that if you could post what graphics card you have and you if its on XP or Vista, that might be helpful.

TinDragon · « **Reply #4 on:** March 13, 2009 »

yes its using 1024x768 res in a window, and ofc needs opengl but that should be on any xp or newer machine, I am on vista 32bit myself. Not sure why it doesnt run. Hopefully some more people will try it and we can narrow down the probelm.

Rbz · « **Reply #5 on:** March 13, 2009 »

Works fine here, around 2850 fps

TinDragon · « **Reply #6 on:** March 13, 2009 »

Thanks rbz, and wow what gfx card are you running, I know mine is rather low end geforce 8series but I am only getting the 600 in the screenshot. Havent checked the engine out on my XP machine with a radeon but that one os even lowend lol.

matthew · « **Reply #7 on:** March 14, 2009 »

If it helps any, I'm running Vista on a laptop using Mobile Intel 965 Express Chipset for graphics.

I was wondering whether or not I was missing any dlls so I tried running Dependency Walker on the exe & it said I was missing IESHIMS.dll.

Apparently it's a dll related to Internet Explorer & I'd recently installed IE8 Beta.

So I uninstalled it but still couldn't get the demo to work, sorry.

TinDragon · « **Reply #8 on:** March 14, 2009 »

I have no idea why it would say it needs anything to do with internet explorer, its a simple blizmax exe using opengl, if you can run zawrans code then you should be able to run mine, its the same language

I really have no idea why it isnt working for you. Only thing I can say is maybe lack of opengl support on the laptops video drivers but I doubt that to be honest, especially if you can use zawrans exe's.

Rbz · « **Reply #9 on:** March 14, 2009 »

Quote

...and wow what gfx card are you running...

Tested it on my Geforce 8800 + Core2Duo 2.40Ghz.

Quote from: TinDragon on March 14, 2009

I have no idea why it would say it needs anything to do with internet explorer, its a simple blizmax exe using opengl, if you can run zawrans code then you should be able to run mine, its the same language I really have no idea why it isnt working for you. Only thing I can say is maybe lack of opengl support on the laptops video drivers but I doubt that to be honest, especially if you can use zawrans exe's.

That's weird indeed, the problem could be with your "pixel format" setup, can you show us how you are doing it ?

TinDragon · « **Reply #10 on:** March 14, 2009 »

I am not setting the pixel format up at all rbz, I am using blitzmax GLgraphics command to open the screen which as far as i am aware does all the needed stuff like that, same as I believe zawran and pixeloutlaw are probably doing in there bmax opengl programs.

On the engine front, reworked my code so that meshs are seperate to the entity and only reference by it, makes no visual difference but the memory footprint shrinks and it also ment I can now have different types of mesh other than displaylists. This means I can also look at getting some form of model loader into it, will have to reference Zawrans examples and see what I can come up with, but first I need to add textures to the system and get them assigned to entities since at the moment I am just adding a global texture used on everything.

Here's a shot anyway showing my first experiemt with a light source.

TinDragon · « **Reply #11 on:** March 14, 2009 »

Here's a new test version of my progress so far, textures are now set to entities rather than global so now more can be done as each entity can have its own texture, the light source is still seperate to the rest of the engine but thats my next target, a system to create position and deal with lights. Then on to get some interesting geo in

cheers
Jon

zawran · « **Reply #12 on:** March 14, 2009 »

Your test runs smooth and fast on my system. Good to see you are getting further with this. I like the texture as well

Shockwave · « **Reply #13 on:** March 14, 2009 »

Totally smooth, about 1,000 fps, nice to see you coding again.

Seems to me like you are using an unusual method of delta timing, are you measuring the frames drawn over a second?

TinDragon · « **Reply #14 on:** March 15, 2009 »

I am calculating the delta like this

Code: [Select]

fpsdelta=(60.0/Float(iFramecounter_framerate))

fpsdelta is a float and all the values its used with are also floats, so the rotation is increase 0.5*fpsdelta with the desired rate being 60fps, I know my code to calculate the acutal frames per second is correct as it matchs fraps 100% for value. Are you getting strange results or something? Only thing I did do is set the fps to 900 at startup so there's not a sudden jump from superfast to slow rotation, but after the first fps value is actually calculated it should be pretty smooth unless you get big jumps up and down in fps rapidly

cheers
Jon

Shockwave · « **Reply #15 on:** March 15, 2009 »

It works fine unless the window is moved, which makes the speed increase for up to half a second.

You could stop that happening if you just measure the time that the last frame took to draw and based your calculation on that, mind you there really is nothing wrong with the movement, it's all nice and smooth Jon.

TinDragon · « **Reply #16 on:** March 15, 2009 »

AH I have never actually moved the window when its been running, that is likely something to do with bmax's handling of events, will have a look see if there's some way to monitor that but it might be part of the gui module that i dont have. Still if thats the only hicup I can live with it for now

My next hurdle is working out a way to create and store the normals for objects so that opengl's light behave correctly on them, its easy for the cube and plane as i just set them in the displaylist, but other geo is going to need me to work them out and store them, I need to work out a method of storing them that fits into my mesh storage method for none displaylist objects, will be fun as I didnt consider the normals when i built the types and lists at the base of the engine

Shockwave · « **Reply #17 on:** March 15, 2009 »

Quote from: TinDragon on March 15, 2009

AH I have never actually moved the window when its been running, that is likely something to do with bmax's handling of events, will have a look see if there's some way to monitor that but it might be part of the gui module that i dont have. Still if thats the only hicup I can live with it for now

What happens is that the window stops being updated while it is being dragged and because the FPS is recalculated (I am guessing) every second or so, this is what causes it.

The solution is to calculate the delta value each frame.

Leaving it as it is would not be a problem most of the time, if windows was doing something in the background though it could mess it up quite badly as it is right now.

I used a similar timing routine to this myself some time ago, after complaints from some people I changed it to calculate delta per frame. I don't think it's Bmax's event handling that causes the problem here, it's that you are not calculating the delta value each frame.

TinDragon · « **Reply #18 on:** March 15, 2009 »

Could you give me a simple example of what you mean Shockwave, I have a version of freebasic installed if you want to show a code example. Timing routines are something that I havent looked at in awhile, most of my old blitz stuff was fullscreen 640x480 using my current method, but if there's a better approach I am interested in it

Shockwave · « **Reply #19 on:** March 15, 2009 »

Sure, try something like this;

Code: [Select]

DIM SHARED OLD AS DOUBLE
DIM SHARED DELTA AS DOUBLE
DELTA=1

WHILE (ESC NOT PRESSED)

  OLD=TIMER

  DO STUFF
  DO MORE STUFF
  DO EVEN MORE STUFF

  SLEEP 1 (GIVE SOME TIME BACK TO THE SYSTEM AND ENSURE DELTA >=1)

  DELTA = (TIMER - OLD) * SOME_FACTOR

WEND
END

The idea of this is to use the variable "delta" as a factor to multiply all movement by so if the last frame took a while, delta would be higher so the next frame needs to move more, if it's running really fast it's cool too because Delta is always in the correct proportion.