Dark Bit Factory & Gravity
GENERAL => Projects => Topic started by: TinDragon on August 15, 2008
-
Well since I hadn't played with code for a while I revisited my conversion of TTD's blitz2d vector engine to blitzmax, everything is exactly as it was in the old engine apart from the actual triangle drawing code, which currently uses blitzmax default polygon command tho I could convert it to a pixelwise based system using my tinyptc lib and I suspect it would still give good speed. It seems to run reasonably well on my system and I thought it might be nice to let others see it in action.
This little example is interactive, you can switch between 2 background colors, switch between the different rendering methods and switch between lightsource calculation methods as well as turn vsync on and off.
For those interested the lighting methods are:- positional with face direction check and fall off, none, depth based, positional distance based. The engine can support multiple light sources and negative lighting but its all based on some rather strange maths that I came up with which works but is very cpu heavy and I suspect could be done far better if I actually had a clue what I was doing :D
Anyway here's a screenie and the test :)
-
Yep, that's strange, the lighting calcs really do seem to have a bit effect on the frame rate, it all seems to work nicely though.
I am not so sure you'd be able to get the same speed with that resolution with software rendering, in fact I'd go as far as saying that probably 800 * 600 is about the limit even if the code is really well written.
Unless it's just as a programming excercise then I'd see no reason to change from the render method you're using at the moment. It works well and looks nice.
-
Great to see you back at coding again :) And your test looks great too. I like the glenz with the outlined wireframe, it looks really nice.
I would just stick with using the polygon command, as there really isn't much need to go back to doing software rendering, unless you really want to, and are going for a specific look. If anything you could dabble in switching it to raw openGL to give you more options of manipulating things on a lower level.
[off topic]
I have been in slump coding wise lately, but seeing you back at it got me started again, and I have been working on a couple of things, just not this week where I have been out sick. But yeah its great getting back into it again, I always start to miss it after a while and is always glad to start again. Btw I am going to work a bit on the game this weekend :)
[/off topic]
-
A solid 60Hz here in all modes, and closer to 200Hz with vb-sync off.
Jim
-
The text just appears in a solid white bar at the top and the bottom.
So, I cannot read the fps-rate. But it runs smooth and I really do like
those cubefields.
-
Yes here is a picture of what I got. Looks like some problem with transparency for the text...
Still quite nice. :)
-
Thanks for the feedback guys.
I have no idea why the text isnt working, its again a standard bmax command, the only thing I did was ensure it compiled to use opengl rather than the default dx7 mode as for some reason dx7 is slower. Seems strange as I havent seen that error before could be internal gfx cards or something maybe.
Could you let me know what gfx card make/model you have?
-
I think certain openGL drivers does create those white squares, so if those with the problem could perhaps check their drivers and report back, then Jon could compaire with what he got to see if the problem could be related to the drivers.
-
happens on some drivers, yes. I had this problem once and setting the filtering mode just after binding the texture fixed the problem. Some drivers do not keep texture parameters correctly and you have to set them again after binding the texture
-
I have no control over the texture of the inbuilt bmax drawtext command tho since its part of the language so it would mean ANY bmax program using that command will fail on those machines if the bmax code is set to use opengl to render. TBH I wouldnt use the inbuilt text command for anything other than debug code but its wierd its failing for people.
I will attach a directx version and if people can check that for me :)
(does help to attach the exe rather than part of the source that dont do anything :-[ )
-
Works fine, but as you said, it's a lot slower. Drops to 30 and maxes out at 100fps.
Jim
-
It might be worth it to make your own drawing functions using raw openGL. Its not much code needed, and this way you get to control how and when things are done.
-
The new version is working correctly!
This is very cool it was nice to see different polygon drawing modes.
-
Glad you were able to view it correctly and it does point to it being an opengl error then since the code is exactly the same I just told bmax to use dx rather than opengl.
What graphics card are you on pixeloutlaw?
-
Ati Radeon Xpress 1100. Probably a very low end card, came with my Acer Laptop computer.