Freebasic Practicalities

[Xalthorn]

I'm curious...

I've always avoided programming things for PCs because of the chaos and unknown factors of the target platform.  Which OS is running, how much memory, what sort of processor, graphics card, etc etc.

Now I've had a play with freebasic and I'm essentially treating it as a pixel canvas, I'm toying with the idea of coding up one of my long term projects.  Before I get started, I'd appreciate people's views on the practicalities of such an exercise.

I get the impression that Windows Vista can't run pure DOS Exe's without doing something special and I'm concerned that if I think about using OpenGL or DirectX (2D and 3D) that there will be portability issues there as well.

Is this something I should be overly concerned about?  Or are there known methods to deal with this?

The project I have in mind can be done in either 2D or 3D, 3D being arguably the more interesting.  If I stay in 2D, I can just use the pixel canvas and do everything by hand, but if I jump to 3D it makes sense to start learning about existing libraries to do the grunt work for me.

[benny!]

I am not used to freebasic - but in general:

What about using abstraction libs that do care about most os-specific
stuff and gives you lot of useful functions on the top. A lot of problems
are already solved - so more time to focus on the creative part instead
of dealing with technical issues like certain OS.

There are several libs/projects around - a lot of solid and good ones -
but you need to check it for yourself against what you require from them.

I can think of:

http://www.libsdl.org/

http://hge.relishgames.com/

[ninogenio]

hi xalthorn if you want to aim your stuff between vista and xp opengl or directx, in a win32 framework is definitly the way to go. in general most win32 stuff will work between the two platforms.

the only time you might encounter compatibilty issuses with ogl are when you start to use extensions which are supported for one card and not the other. extensions are there for when something that the basic opengl cant do which most of the time is sufficent enough.

although these problems can be taken care of with a bit of carefull coding.

onto the 3d/2d thing with ogl you can do both. for 2d pixel pushing you need to use a texture like a front buffer and alocate some space for a backbuffer in memory then you can push your data over each frame and display it maping it to a quad. ive tried this and its really quick just as quick as ptc i would say.

the only problem is that the texture has to be to the power of 2 so if you wanted a 640,480 screen you could create a buffer 512,512 and scale the texture up through the vertices of the quad.

i have working code laying around so if you need to look at anything just ask.

[Shockwave]

As Nino says, Opengl is a safe bet as long as you stick to power of 2 textures, np2 textures run really badly on ATI cards.

Stick some delta timing into what you do though and it should run nice on just about anything.

The same goes if you decide to stick to 2D programming, I suspect that you'd have a lot of fun writing it in 2D actually.. You can make things look quite wonderful with software rendering, opengl is the one to go for if you want to throw a lot of geometry around.

[Jim]

fbc only makes Windows EXEs, so no problem with Vista.

Jim

[Xalthorn]

Okay, sounds fairly safe.  One thing that concerns me though is libraries.  It reminds me of the huge minefield of choices when considering assorted 3D engines, not to mention you have to learn how to use the libraries.  I rifled through the forums looking for OpenGL stuff and have realised that I have to learn a whole bunch of new commands.  This is fair enough as it seems that OpenGL is 'simply' a rendering pipeline where you throw states and polys into the pipeline, flushing occasionally and letting the thing do its job.

I suspect I'm falling foul of library issues with FB already.  I've had comments on my demos that I should upgrade to the latest version, but then I'm wondering what would happen to the existing 'forum specific' library that I use to do the demos in the first place.

As an aside, this delta timing thing.  Unless I'm on the wrong track, isn't this the theory of moving things around the scene based on the amount of actual time that has passed?  If so, surely a slower machine would look jerky as things jumped to their calculated position rather than just running slower?  Although I suppose it can be used to modify the detail/quantity of things on the screen to keep the rate up.