[Nuke]

ok this is more an opengl and me trying to run fs2open on something way below the requirements problem. i figured this laptop i got should just be fast enough to use to develop scripts for the scripting system. now this laptop i got has some 3d, and by some i mean an 8-meg s3 savage ix which only supports opengl 1.1 (drivers are fully up to date and long sence discontinued), while fsopen requires a minimum of opengl1.2. now i was able to run the game in d3d mode after some fighting with it, and it ran fairly well in 16-bit mode. playable and the scripts i tested ran fairly well. now i know that d3d's gonna get pulled from the code sooner or later, and also i cant seem to get fred to work as it also requires 1.2.

now is there any utils out there that anyone knows of to abstract opengl 1.2 down so that it can run on top of opengl 1.1 so that i can run sutff in the future?

[taylor]

The 1.2 requirement has been removed for the most part, though it does still Error() out if you don't have at least 1.2.  1.1 is known to work on the Mac however.

The big problem is that you won't be able to get HTL, and software mode doesn't work all that well.  I am in the process of upgrading the code so that the differences between HTL and non-HTL modes aren't that great.  There is little difference between the two actually, as far as OpenGL is concerned, so the code path can be greatly simplified from what it is now.

It's something of a moot point though, since the plan is to actually raise the OpenGL version requirement to 1.4.  We already have 3 or 4 ways to do most rendering in the OpenGL code, due to having to support everything down to 1.2, so this version bump would allow us to simplify the code.  OpenGL 2.0 and 2.1 features are already getting coded in so the work of fully supporting everything is getting far more involved/complex.  Plus, a totally new render API has to be written for OpenGL 3.0 support, so we have to prepare for that as well.

I can't promise anything, but I will try to improve 1.2 and pre-1.2 support with basic features (ie, no glow/spec/env/HTL etc.), assuming that you can be available to test out some builds so that I know I'm going in the right direction.

[woutersmits]

i think that your laptop vidio card to change to nividia geforce fx go 5700 most you have than it works

[Nuke]

im really just needing the game to run at a very basic level so i can test scripts when im away from my other machine. i really dont need htl because im using vanilla data only. anyway dont hold back dev in other areas over this as this is more or less something that i can live without. i figure my best bet would be a wrapper of sorts.

[akenbosch]

isn't nukemod HTL?

[Nuke]

yea somewhat, but thats not what this is for. i do all my script development with vanilla data. if it works well under a clean set of datafiles it in theory should work well under an htl-rich mod. my big reason for separating script development from nukemod development is speed. it takes less time to load a few retail ships with 8 bit maps than it does to load some of my huge textures and models, so i get better loading times which is key to fast debugging.

the other reason is the dynamicness of head builds. some features ive implemented may or may not cause errors with various builds, such as up-to-date cvs builds or builds from individual coders' codebases. i have found that removing this layer of potential errors speeds up the dev process. i also do not feel that most of my scripted features are ready for mod-integration at this point.

nukemod has actually stagnated quite a bit sence i decided to learn scripting. i figure all the features i plan to make for the mod will make it worth the wait. sence my work season is comming to an end i hopefully will pick up at where i left off as far as modeling goes. i hope to have another mod release around the time 3.6.11 comes out, by then all the new scripting stuff will make it into the stable branch.

[Nuke]

another thing i found out while messing around with the laptop is that the game refuses to run if it doesnt find dx8, even if youre running open gl. bug or does it still use some directx functionality under windows, such as direct imput?

[taylor]

another thing i found out while messing around with the laptop is that the game refuses to run if it doesnt find dx8, even if youre running open gl. bug or does it still use some directx functionality under windows, such as direct imput?

Depends on your build.  Builds based on the stable branch have already had the DX8 code disabled, but HEAD builds and older builds still require it, even if you aren't actually using DX render mode.  The DirectInput code is version 5 or something like that, as I've never upgraded it since the plan has always been to ditch it in favor of the unified SDL based code.

[Nuke]

ok, i thought id try and get around the problem by switching the laptop over to ubuntu. i put in a better hard drive so needed to reinstall an os anyway. thought id give ubuntu another chance. anyway i fought with it to get the game to compile, and it seems i remembered the procedure and got a cvs build. so i get my dir together and i get this

nuke@N3kr0g3dd0n:/home/fs2$ ./fs2_open_r
ERROR: "The required OpenGL extension 'GL_EXT_texture_env_add' is not supported by your current driver version or graphics card." at graphics/gropenglextension.cpp:395

does this mean i dont have a chance of running the game on this machine? seems to me that this gl extention would only need to be used for env mapping, if i read the discription right, dispite the fact i have most everything disabled.

[WMCoolmon]

I was trying to use FS2_Open on an IBM Thinkpad T22 and had the same problem. I had the same idea, too. I've always figured it would be possible to create some neat games with scripting, someday, and avoid the massive overhead that would be involved in writing the game from scratch yourself.

Actually IIRC my 'fileless Freespace 2' subproject was inspired by trying to get it to run on that T22...

[Nuke]

i was thinking about fs2_open retro. same great game but with tron-esque graphics designed to run on the ultra low end

anyway i think my game engine im writing in c++ is growing some potential. i can fly around the world now. unfortunately my line draw function is way too slow. im doing everything with sdl, so everythings running in software. its all linedraw. i think the main source of my problems is that my line draw function is too slow. sence its being called a hundred or so times a frame it needs to be ultra effietient. also for some reason my sdtout is missing so all my debug messages are vanishing off to oblivion somewhere.