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

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

Your example is basicly delta timing, thats what my code actually does but linked to the frame update rate, and it then changes all movement/rotation * that delta amount. The problem with moving the bmax window is that while your moving it the code gets paused but the timers dont so it thinks its taken longer to render the frame than it should, it then changes the delta based on this time and takes approx 1second for the timer check to catch back up to the actual time.

Now I guess I could uncouple it from the frame rate and use instead some realworld length of time but again it would likely go out for a second due to how the bmax window seems to behave, would depend at what point bmax paused the code if it was just after you set OLD=TIMER and you moved the window for awhile then the timer is going to have increased alot so when you do the delta calc its going to surely still be wrong until you loop around next, but it wouldnt I guess take the 1second my fps based code does.

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

Quote from: TinDragon on March 15, 2009

Your example is basicly delta timing, thats what my code actually does but linked to the frame update rate, and it then changes all movement/rotation * that delta amount. The problem with moving the bmax window is that while your moving it the code gets paused but the timers dont so it thinks its taken longer to render the frame than it should, it then changes the delta based on this time and takes approx 1second for the timer check to catch back up to the actual time.

Yes, this is what I described as your problem pretty much.

My solution sorts it out, it's worked in everything I have released for the last 2 years anyway, and in productions by several other people I gave the same advice to.

RBZ did a nice example somewhere as well, I'll try and find it for you.

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

Well if you would like to try this version out I think it should now behave more correctly when you move the window with out speed up or slowdown and you can toggle vsync with F, its off to start with. I seems to work at my end, not sure how it would do for any form of music syncing but I rarely do that anyway lol

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

Perfect.

Clyde · « **Reply #24 on:** March 16, 2009 »

If its any concelation, on my spec ( see signature ) i get a respectfully 92-95 fps.
Welldone on the Z-Ordering / Sort too.

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

Quote from: Clyde on March 16, 2009

Welldone on the Z-Ordering / Sort too.

Opengl does all that for you Clyde

Pixel_Outlaw · « **Reply #26 on:** March 16, 2009 »

Looking good!

OpenGl is really great to know and use.

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

Wow Clyde thats actually very suprizing, I would have thought eveyone would get a couple hundered fps on such a simple scene even on very old gfx cards, Its not like its a doom3 level engine

How does zawrans code run, tho not sure he has fps display atm.

On the actual engine front, not made any progress at the moment as I am looking to redesign my mesh handling so that I can store normals for lighting, the simple cube and plane displaylists have them pre set since there easy but I need a way to create and store them for models that are loaded in etc. and my current code doesnt offer a way to do that. But it should hopefully just be a case of reworking the mesh type's methods once i work out a sensible structure for the information

benny! · « **Reply #28 on:** March 16, 2009 »

Just saw the whole thread and downloaded all releases
of the last days. Runs very smooth here. Very well done!

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

Thanks Benny, it came together very well up to this point but I have hit a snag with opengl lighting, it works fine if everything is textured or if everything isnt but I am getting probelms when i try to mix textured and none textured, I probably need to change certain state variables and such but every exmapl I have found makes my textured objects either seem to go full bright or take on the color of the non-textured object.

Still I have my new mesh setup ready to go so now I can try to get a model loader going and thanks to zawrans posts in the blitz forum I have somewhere to start

Jim · « **Reply #30 on:** March 16, 2009 »

Quote

The problem with moving the bmax window is that while your moving it the code gets paused but the timers dont so it thinks its taken longer to render the frame than it should

That can be a problem. The OS might go off for a sleep, or even you might implement a pause button.

One thing you could do is not only have a 1ms fastest rate, but a 30ms slowest rate, so even if everything gets delayed for a second or two, you just insist that it ran at 30fps.

delta_t = max(1,min(delta_t,30))

Jim

matthew · « **Reply #31 on:** March 17, 2009 »

At last I finally get to see it.

Over the weekend I got sick of Windows Vista so I tried installing my XP recovery disks on my Vista computer.

Surprisingly it worked & after a few hours of tracking down the relevant hardware drivers, I'm now running XP.

I was getting about 170 FPS from my Intel card.

TinDragon · « **Reply #32 on:** March 17, 2009 »

Glad to hear you got it going, must have been some vista opengl driver problem with the intel graphics chip.

On the engine front I have reworked my method of storing mesh data with some handy tips from zawran on certain aspects of bmax, the engine was back to the same level within an hour of recoding the needed parts, so I then decided to retry adding a .obj loader based on zawrans code, fun and games have followed with me recoding whole sections and trying different things as i couldnt get models to display correctly or in some cases the files to read in as expected, turns out there are versions of the .obj file that are not standard and this caused me some headaches, but I couldnt load a file zawran could, which is wierd when the actual part that reads the data from the file is the same. After some tweaking it started to load the files I have been getting out of a 3d model converter i got off the net but it appears UV and normals are not working as intended, but I present a screenshot for those following the thread. Its a taxi model with its texture but as you can see its erm borked, still atleast I can get some different geo to a cube in

Cheers
Jon

zawran · « **Reply #33 on:** March 17, 2009 »

This is both good and bad news to me. Its bad news because it shows that my loader function does not work as intended, but its good news because it shows that my loader code does not work as intended

I will work on the code the next couple of days to see if I cannot get this working as I am going to be needing a working model loader soon.

Clyde · « **Reply #34 on:** March 18, 2009 »

Looks to me as if some triangles are facing the wrong way.

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

The triangles were actually drawn correctly untextured it looked fine

, some look wrong due to the black parts of the texture, zawran got the taxi to load and display textured correctly in his engine and we discovered that the format uses an index UV coord set, so were i I thought it loaded in the vu's in the same order as the vertex's it doesnt, which is why the texture UV's are out, but we did discover that some programs dont export the .obj files as the format is ment to be and skip parts, making them not work correctly with the loader so zawrans going to work on it some more. For me its going to need some heavy reworking of the loading code to cover the index'd textures which at the moment I am going to skip, instead I am going to write a little app in b3d to export a model's data to a file in the order I want it so that I can get some models in and check my texture code is working as intended, then I can get lights going and work on other features including model loaders, but I kinda need to see that my code is working right or it will always seem like a loader is broken if its an error else where

Will hopefully post up a working spinning textured model exe later today

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

WooT, we have a correctly texture model in the engine

After coding a little blitz3d program to load in a model and export it to a binary file listing all vertex and face data needed in an order that I picked, then coding the bmax loader for it, I finally got the taxi model in and textured correctly, its a great feeling when something actually works and from this I can tell that my setup for the vertex uv's is right. Now to work on other features, not sure what to tackle next but I am just happy to have gotten this far

Attached is a screenshot and an exe for those interested in testing, F switchs vsync on/off, its off to start with.

Cheers
Jon

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

Well for the success of getting the model in and drawn another error appears, I didnt notice it at first but if you look the taxi and number plate writting are backwards, the realy craze thing is after looking over my code and the exporter, and how b3d handles models, the model should be inside out as b3d uses CW poly winding and my engine uses opengl's CCW :S

I dont know how to fix this and am starting to think I should just scrap this altogether

benny! · « **Reply #38 on:** March 18, 2009 »

Runs very smooth here. And even smoother with vsync off.
Nice model btw and good work!

hellfire · « **Reply #39 on:** March 18, 2009 »

Quote

the model should be inside out as b3d uses CW poly winding and my engine uses opengl's CCW :S
I dont know how to fix this and am starting to think I should just scrap this altogether

I strongly believe you just have one axis of your vertex-coordinates flipped.
There's no correlation between polygon-winding and texture-orientation.