Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Inquisitor on May 27, 2002, 11:19:49 am
-
Penguin, vrodic, et al:
Are you keeping the openGL renderer seperate for now? Meaning, can the code you are working on, if compiled on a windows machine, still render in the DX mode? Or did you rip it out entirely?
-
Originally posted by Inquisitor
Penguin, vrodic, et al:
Are you keeping the openGL renderer seperate for now? Meaning, can the code you are working on, if compiled on a windows machine, still render in the DX mode? Or did you rip it out entirely?
All the OpenGL stuff will stay in Graphics/gropengl.cpp, with the exception of a few external calls (ones that call gr_opengl_init, etc.) The DX, Glide, etc. code is not getting touched at all. I have added a fair number of ifndefs around the DirectX-specific stuff to get it to compile, but no code changes.
-
What advantages does OGL confer onto us? Speed? Visual? Or is it more for Linux?
-
Mostly for cross platform. Many people prefer the performance of OGL applications as well.
That's good news Penguin, that's what I thought it was, that means, that if we so desired, we could update some stuff to dx8.
Just thinking thru what all can be done, not saying it should be :)
-
IMHO OpenGL's better then DirectX. Or at least the DirectX as used by the engine. Of course, for me Glide is even better but I will check out the preformance of the OpenGL port. And when it's released I will see if it will compile under PS2Linux. One thing I just thought of, do non-X OpenGL apps run in a seperate virtual console? (or whatever you call the various Alt+ modes)
-
Originally posted by EdrickV
IMHO OpenGL's better then DirectX.
I guess I agree with you. Both are good, but OpenGL is very fast and usually I think games that use OpenGL even look better.
You can do much in OpenGL (Doom III):
(http://www.gamespy.com/e32002/image.asp?/e32002/pc/doom3b/9.jpg)
But Glide was best of them all, but all of those API's are good. :nod:
Edit: :wtf: I wonder why image tag doesn't work...
-
That's good news Penguin, that's what I thought it was, that means, that if we so desired, we could update some stuff to dx8.
I assume that would also bring desireable performance enhancements and potential graphical enhancements too?
The big thing for me is that specular lighting and bump maping would really make FS2 look good. Graphically it still holds out but pushing it a bit higher would really bring it up to date. Maybe im being idealistic :D
-
Originally posted by IceFire
I assume that would also bring desireable performance enhancements and potential graphical enhancements too?
Well, so far performance isn't so great, at least on the 2D side (3D is still :mad: under construction...) I have read in various places that most OpenGL implementations are not optimized for 2d (DrawPixels, etc.) so this is no big surprise. But the framerate in the 2D environment (eg command briefings) gives me about a 3 or 4 fps... the ANIs are somewhat jerky.
I have a reasonably fast machine -- 550MHz PIII w/ 128MB RAM and a GeForce3 Ti200.
A lot of stuff is not optimized at all, and this is debug mode, w/ lots of mprintfs, so hopefully we will be able to squeeze more performance out of it. Obviously the in-game framerate is more important, and there is less 2D there -- just the HUD overlay.
The first step is getting it to work at all -- plenty of time for performance tweaks.
I flew a mission yesterday from start to finish on my Linux box ("Surrender, Belisarius!") :D :D :D It was odd flying around w/ no 3d images, but the keyboard and targeting controls worked, so at least I could tell where the bad guys were and launch Rockeyes at the red lead indicator.
-
Is anyone else this far along? That's excellent that you actually have it working to some degree. Could you kill anything?
vrodic? You made any more progress?
Has Kazan released his openGL rendering code?
BTW, I'm told that our group CVS is in the works, sent a follow up this mornign to get an ETA, still think it might be a good idea to have a quick realtime chat :)
-
Originally posted by Inquisitor
Could you kill anything?
Yeah, according to the debrief, I got two Hercs (I dunno, I couldn't see anything ;) ) My primary hit rate was 0%, but secondary was 78%, not bad for flying blind, IMHO :p
-
Originally posted by IceFire
What advantages does OGL confer onto us? Speed? Visual? Or is it more for Linux?
It would probably go a lot faster than the old version of directx that FS2 is using(5?), and I doubt theres anything in there that OpenGL couldn't do...
-
Originally posted by IceFire
What advantages does OGL confer onto us? Speed? Visual? Or is it more for Linux?
Just for clarity, OpenGL is the way to go. I don't care so much about faster (its plenty fast enough!), but if you've ever tried to decipher Direct3d functions and OpenGL functions, you see that the OpenGL is almost (but not quite) human parsable.
Other than that OpenGL is just cleaner than DirectX.
-
Direct X doesn't take the full advantage of my video card.
But OGL would
-
Originally posted by mikhael
Just for clarity, OpenGL is the way to go. I don't care so much about faster (its plenty fast enough!), but if you've ever tried to decipher Direct3d functions and OpenGL functions, you see that the OpenGL is almost (but not quite) human parsable.
Other than that OpenGL is just cleaner than DirectX.
Considering OpenGL was originally developed by Silicon Graphics for workstation use thats hardly surprising...
-
Originally posted by Inquisitor
Is anyone else this far along?
Yes.
http://icculus.org/~theoddone33/files/tricky.png
http://www.icculus.org/~relnev/the_dark_master.png
Screenshots both taken on Linux.
Sound and joystick input do not work as of this writing. OpenGL graphics are done.
Neither of us has the full game yet, so we've been basing our work on the demo.
-
Now we just need it up on some CVS server so everyone can combine their efforts. :)
And so I can see if it'll actually compile on PS2Linux. ;)
-
Originally posted by Admiral LSD
Considering OpenGL was originally developed by Silicon Graphics for workstation use thats hardly surprising...
Nah, it has nothing to do with that. It's all about how the API was laid out. That's hardware agnostic, really. When they put together OpenGL, they went for a relatively clean namespace (for lack of a better term). Direct3d's layout, on the other hand, is messy and disjointed, with functions inheritting naming conventions from other function families that are only vaguely (if at all) related.
It makes OGL code easier to read and follow than DX code, at least from my point of view.
-
DX code makes me want to puke
-
theoddone!
dude, that's excellent. Willing to share with the rest of us?
Lemme bug the CVS people again. Be a shame if there was this much duplicated effot :(
-
This really is very promising :nod:
You are very welcome to HLP theoddone, that's excellent work :yes:
-
theoddone:
Just saw that you don;t have the game yet, I ran across a couple copies on ebay recently, for less than 20, if you are having a hard time locating it.
And who is "we" ?
:)
-
Originally posted by theoddone33
http://icculus.org/~theoddone33/files/tricky.png
http://www.icculus.org/~relnev/the_dark_master.png
Screenshots both taken on Linux.
:eek: ;7 :eek:
Sound and joystick input do not work as of this writing. OpenGL graphics are done.
Neither of us has the full game yet, so we've been basing our work on the demo. [/B]
Don't have Freespace 2!?
:jaw: :jaw:
Nice work! :yes2::nod::yes:
-
why don't all you people put what you've all got together
-
Because we just got a common CVS server about 5 minutes ago :)
That IS the plan Bobboau ;)
-
Very sweet.....
So let me try and undestand some stuf here :)
OpenGL is a alot easier to understand and presumably implement into FreeSpace 2? OpenGL could potentially perform faster than Direct3D in FreeSpace 2, if only because FreeSpace 2 is built on DirectX6?
Would this also potentially allow for us to do something like say add bump mapping or specular lighting to the engine without doing any serious damage to the speed at which we can play it?
I'm not expecting anyone to be able to bring FreeSpace 2 up to Unreal Warfare or Doom III leve by any means but I think it'd be cool if we can keep the game running smoothly plus add some graphical enhancements to keep things looking good for a while yet.
-
Here's the real trick:
I can check in a vanialla copy of the source, but who;s port in progress should we build from? Guess we won;t know that till we look at each of the 2 ports that are the furthest along.
theoddone and penguin (and vrodic, though I am not sure how far along you got past the GCC compile, and eldrick, just for grins) we need to get together sooner rather than later so we can get your CVS set up and figure out what is what :)
-
FreeSpace 2 is built on DirectX6?
Try DirectX5, sparky ;)
If I had a say, I'd say to stay with DirectX. Partially because I'm impressed with DirectX 8.1 (how it compares to earlier versions), and partially because every would-be graphics wizard can be overheard to say "OPANGL SI THE BEST! DARECTX IS FOR LAMARS. JOHN CARMACKE USES IT!" if one spends enough time.
And also because I'm just stubborn and refuse to admit to the possible benefits of OpenGL :)
In seriousness though, you're not going to see any significant speed difference between GL and DirectX, especially with a game like FS2. You'd need to do some serious CPU-side optimizations to the model rendering code before the vagaries of API/drivers start to come into play. Of course, its been 2+ years since I've seriously played with the code, so I could be on crack.
-
Well, no DirectX upgrade will run on Linux or the PS2, so we have to have something else for at least those parts.
I'm in favor of keeping/upgrading DX for the windows users, if not offering them a choice.
But that's me.
BTW, initial checkin of Voltion source into CVS just finished.
We're in business ;)
-
Actually the most valuable thing to do, would be to create an API agnostic renderer for freespace2 ala Quake2, where you simply feed the various render commands to the renderer, and then the currently active backend (opengl/direct3d) does the appropriate api calls, a lot of games use this approach, even recent ones like Serious Sam. A lot of video cards now have excellent opengl drivers (sometimes better than d3d) while older video cards have much better d3d support, or no real support at all (glide)...
-
Yeah, that's definately the best way to handle the render code.
Inquisitor, like I said in the other thread, either get a copy of the most recent version of the GCC/OpenGL/Linux port or give whoever has that version write access, and have them commit it (perhaps after touching it up to make sure it has a good file/folder structure). IMHO we should use that as the starting point, because it has the most changes. CVS should be able to handle the smaller changes regardless of what the base is anyway, especially because the port changes mostly graphics stuff I don't think anyone else has touched yet :)
-
I'd pay $100 to someone for getting fs2 up to DX8
$200, if they were quick about it
now hurry up before I change my mind
-
Originally posted by daveb
...In seriousness though, you're not going to see any significant speed difference between GL and DirectX, especially with a game like FS2. You'd need to do some serious CPU-side optimizations to the model rendering code before the vagaries of API/drivers start to come into play. Of course, its been 2+ years since I've seriously played with the code, so I could be on crack.
Just out of curiosity, why is the model rendering code such a...well, mess. There's a lot of weird and unfinished things here. :)
Was Interplay a bit pushy?
-
Originally posted by Eternal One
Was Interplay a bit pushy?
That's like asking if the sky is blue. ;)
-
Hahah, yes, perhaps a rather stupid question. :)
-
Trying to get that copy now, Mysterial :)
you'll notice that neither penguin nor theoddone has responded since this news came up :)
-
The bad thing about the OpenGL port (or at least my version, there seem to be a lot floating around)...
Most of the 3d transformations (to screen coordinates) are done by the FS engine itself, and the rendering only displays the 2d polys. And as I've posted before, OpenGL kinda sux at 2d, so the framerate is very bad (about 3-4 fps on my box). It would be a lot better to move all the 3d rendering out of the engine and let OGL do it natively. We would still use the 2d for the UI and HUD overlay, I guess... Of course this would have to be conditional code, so DX, etc. wouldn't break.
Another idea would be to move all the UI graphics (menus, etc.) to use the "native" rendering -- (Xlib for unix/X, GDI for Win32), so we're only using OpenGL in-game. But this would be a lot of work, epecially since Xlib has no concept of alpha blending, and IIRC neither does GDI (but it's been a while since I did Win32 programming...)
BTW, kudos to theoddone33 and co... looks awesome, I'm jealous ;)
Inquisitor, I can get you what I have. It is butt-ugly code, but 3d rendering is about 50% done -- no texturing, so ships, etc. are being rendered as kinda ghost images, but it's almost playable except for the crappy framerate. Lemme know how you want to handle it, AIM or email me (I just installed LICQ and have no idea if it works or not w/ my firewall, but you can try it too)
-
Lets all get together and compare notes, penguin :)
-
So is DirectX 8 stuff available to us....like does Microsoft have whatever tools needed for you guys to try and make that upgrade? Is that beyond your abilities?
I know im asking lots of questions but I want to try and get a grasp of what can and cannot be done. I'm about to embark on a new FreeSpace project and source code and MODs is where its at so I'd like to be able to take advantage of and have an idea of what we may be able to do in the future.
Try DirectX5, sparky
Dizam....I thought it was 6....I guess I lost count :D
-
So is DirectX 8 stuff available to us....like does Microsoft have whatever tools needed for you guys to try and make that upgrade? Is that beyond your abilities?
Yep, you can download the DX8 SDK completely free. The full download is a little large (almost 200 megs) but well worth it. The documentation is excellent.
As far as an API agnostic renderer. That's exactly how FS2 is setup. The high level game code doesn't know whether its in DirectX mode, or OpenGL or whatever. It is indeed handy if you want to be "flexible". However, what I've basically found out over the years is that the agnostic renderer is going to cost you in performance. Not really because of the middle layer, but because every API is slightly different (admittedly, these days they're pretty much all converging to the same feature set) and you're going to be making assumptions to get something working in one API that don't necessarily hold true for another.
For example, if you were to use DX8 you could go full out and create all your vertex buffer and DX8/hardware specific stuff in video memory and work from there. However, there's no analog for that in OpenGL at all (OpenGL likes to "hide" the details from you). So, like in FS2 you write for the common denominator, and do all your transforms on the CPU and use the API as a pure rasterizer.
This brings up a good point. The poster before who talked about OpenGL not being good at "2d" and therefore being slow with FS2 - that's completely untrue. FS2 uses its hardware API (Glide, DX, etc) purely for rasterizing. There should be practically 0 difference between them. I would suggest that the reason your OpenGL implementation is slow is because _you're_ making the wrong assumptions about what the code needs to do and how OpenGL works. That's not meant as a slight - but it illustrates the point very clearly - if you insist on multiple API's you're going to run into ugly roadblocks.
It all comes down to what you want to do with the code. Do you want to take it, possibly make it faster and add a bunch of cool gameplay stuff? If so, stick with Windows, go straight with DirectX 8 and save yourself a _lot_ of time. The whole "we need to use Linux" ideal has always been goofy to me. You're simply not going to beat MsDev for a sleek development environment, you've got a game that works, and DirectX has tremendously useful documentation.
On the other hand, if you just like the idea of porting it to Linux for the sake of porting it to Linux, that's fine. Go with OpenGL and be happy.
But for those who want to actually accomplish something with the game - don't bother. It'll be ages before you see a "useful" OpenGL Linux version and it'll be fraught with incompatibilities and hassles that will hinder your desire to do something with the _game_. You can start right now, this second, doing stuff with the straight up Windows/DX game code. The idea that somehow a Linux/OpenGL port is going to help you is a very silly myth. Cross platform, cross API development is more of a hassle than you need. Let the OpenGL/Linux guys do their thing, it'll be a fun project. But its going to seriously hold you back if you're a simple game developer. If you're really ambitious, someone can be updating the underlying Windows graphics code to DX8 silently underneath you, and I _guarantee_ that if its well written it will be every iota as fast as the mythic OpenGL/Linux beast (in either case, as I said before, simply swapping API's is going to get you knowhere - you're going to need a big effort to overhaul the model rendering code)
(wow, this ended up as a rant).
-
Isn't Dave just the best? ;)
-
Well, the intent of this post was to see what the OGL people were doing, in terms of preserving the existing windows code, and it sounds like, in at least penguins case, he is keeping the exising code.
So, there's really nothing preventing a DX upgrade to 8 ;)
The OGL gets it in the hands of the mac players, the Linux players (outside of WINEX), and also moves the developers knowledge forward in terms of the renderer on the PS2, does it not?
Now, if only theoddone would come back and get CVS access :)
-
The OGL gets it in the hands of the mac players, the Linux players (outside of WINEX), and also moves the developers knowledge forward in terms of the renderer on the PS2, does it not?
Mac players and Linux players, yes. All 186 of them. And I say that without a hint of sarcasm ;)
I guess my point is - be realistic about things. Take a deep breath and repeat after me - "the odds that there will be a fully functional PS2 port are about the odds of successfully navigating an asteroid field. Unless I'm Han Solo, its not going to happen". The same thing goes for a Mac or Linux port. Sure, it may happen given some motivated individuals. But really, what possible advantage is it really going to give anyone? Yes, for the guys who do the work it'll for sure be a very useful learning experience. That alone probably makes it worth it....for them.
As near as I can tell, guys like Icefire and others want to extend the game. Maybe some new graphics here, a bunch of new gameplay there, some improvements to existing functionality. I tell you this now, as a programmer who has seen (and caused) much folly in his days - this goal is incompatible with those who want to go Whole Hog with the code and make it a cross-platform-multi-API-zippedy-doo-da-i'm-a-smartay-man-lunix-developar spectacle.
You can unzip the code right now, and hit F7 in MsDev, and then F5 and it runs. Guess how many keystrokes it'll take to get the newest rev of the Linux port to run? Include the # of keystrokes requried to get Linux installed and running properly on your machine.
Realistic expectations will get you everywhere.
-
Especially for people like me who can't even get "make" to work right...:doubt:
-
I dunno, it looks like theoddone has part of it working already, in only a few short weeks. Seems mighty realistic ;)
The way penguin has it set up, it's self contained, the msdev stuff still builds :) So the tinkerers can continue to tinker, and the gameplay stuff can get added independent of it.
Some of DTP's stuff is very cool, some bugfixes, some additions, and there have been a few new sexp's added by different people.
Getting it all i nthe same place is step one (and probably harder than the actual coding ;)).
I see a few major avenues of attack, in no particular order:
1) Bugfix (there are a few)
2) DirectX8 upgrade (at least use native DX8 calls, rather than DX5 backward compatibility, control code, etc which will bring us to possibly 3 and certainly 4)
3) Multiplayer redux/Multiplayer bugfix (maybe even a new masterserver implementation ala one of the many open source master servers out there, also, there has to be a way to get more out of the netcode)
4) Gameplay and engine enhancements (ala Icefire)
5) SDL/OpenGL/openAL port for Linux and Mac users as well as to at least pave the way in understanding a possible ps2 for linux port (all 186 of them), perhaps thru this, some advances in the networking can be made as well?
Those are realistic expections, IMHO, effectively silo'd from one another (because the codebase is so modular) that progress can be made in one, without blowing up the others and because we've collectively come some distance in understanding this codebase, and making the codebase more accessible to even windows users of GCC (VS still has a cost) can't be a bad thing ;)
Addresses both the hobbyist GNU coder as well as folks like Icefire's wants and needs. Keeps the code teams seperate, so stalling on one track doesn't kill the others (provided we keep with good practices like penguin's).
It's not just one or the other, this is having the cake and getting to eat it.
So, who wants to look at the DX 8 upgrade?
:)
-
As long as we keep the graphics code seperate and don't do anything stupid that breaks the old stuff, there's no reason some people can't work on porting and others on adding new game features to the core engine. That's why we have CVS.
And yeah, this is most importantly a learning experience for me. I need to know how to do cross-platform. The hardest thing I can imagine in that area is trying to make something that wasn't become cross-platform. Thus, my desire to port it.
After penguin or Inquisitor commits penguin's port, I'll look at the code myself and see what I can do with it. As a sidenote (no offence penguin) I did say we should use SDL. Probably doesn't really matter in this case, though.
-
Originally posted by daveb
This brings up a good point. The poster before who talked about OpenGL not being good at "2d" and therefore being slow with FS2 - that's completely untrue. FS2 uses its hardware API (Glide, DX, etc) purely for rasterizing. There should be practically 0 difference between them. I would suggest that the reason your OpenGL implementation is slow is because _you're_ making the wrong assumptions about what the code needs to do and how OpenGL works. That's not meant as a slight - but it illustrates the point very clearly - if you insist on multiple API's you're going to run into ugly roadblocks.
You are probably right about my making wrong assumptions... and I hope you're right about the eventual performance. This is still a first crack at getting it to work at all under OpenGL and a non-Win32 API. Performance tweaks -- which may very well require massive code changes -- can wait.
The whole "we need to use Linux" ideal has always been goofy to me. You're simply not going to beat MsDev for a sleek development environment, you've got a game that works, and DirectX has tremendously useful documentation.
On the other hand, if you just like the idea of porting it to Linux for the sake of porting it to Linux, that's fine. Go with OpenGL and be happy.
I can handle being called "goofy" :wakka: And yes, MS has an excellent development environment, vastly better than anything I've seen for any other OS ( :grimace: <-- the smiley for salt being rubbed into an open wound).
And porting to Linux just for the sake of it isn't such a bad idea, IMHO. I am trying very hard not to wreck any Win32 specific stuff.
The idea that somehow a Linux/OpenGL port is going to help you is a very silly myth.
Agreed
Let the OpenGL/Linux guys do their thing, it'll be a fun project.
Couldn't have said it better myself ;)
Mac players and Linux players, yes. All 186 of them. And I say that without a hint of sarcasm ;)
Hey, there are at least 200 of us, where do you get your statistics ;) ;)
I guess my point is - be realistic about things. Take a deep breath and repeat after me - "the odds that there will be a fully functional PS2 port are about the odds of successfully navigating an asteroid field. Unless I'm Han Solo, its not going to happen".
Hmm, if I remember my astronomy correctly , asteroid fields in real life are a lot less dense than those in Star Wars (or FS for that matter :p)
You can unzip the code right now, and hit F7 in MsDev, and then F5 and it runs. Guess how many keystrokes it'll take to get the newest rev of the Linux port to run? Include the # of keystrokes requried to get Linux installed and running properly on your machine.
:grimace: AGAIN!
And yeah, this is a long-term thing. If people want to go putting beams on bombers, or cloaking devices, etc. than I do not recommend they wait for the linux port ;)
And finally, thanks for staying involved, daveb. Sorry if I come off as being too defensive :) This ended up being way longer than I had planned.
-
Originally posted by Mysterial
As a sidenote (no offence penguin) I did say we should use SDL. Probably doesn't really matter in this case, though.
None taken -- I am using SDL! You and kazan and a few others recommended it and I'm glad you did. It is working very well.
Right now I'm just using it for video/keyboard/mouse, but the joystick and sound look like they'll plug in nicely.
-
Originally posted by daveb
You can unzip the code right now, and hit F7 in MsDev, and then F5 and it runs. Guess how many keystrokes it'll take to get the newest rev of the Linux port to run? Include the # of keystrokes requried to get Linux installed and running properly on your machine.
Realistic expectations will get you everywhere.
I can't do that. And I know there were other programmers interested in toying with FS2 that couldn't either. Why? Because we don't have VC++ 6.0. I have 4.0 but it won't compile. If not for the GCC port I wouldn't be able to do anything with the source code except look through it. And VC++ 6.0 is not easy to find locally. Nor am I going to spend $100+ on a compiler I would only use for one program. (I've had too many bad experiences with Microsoft written software, in particular the WMP 6.4 Active X control, to want to use VC++ for programs I want to make and use. I want my programs to run, not crash as Windows often does. :))
Sure, a Linux port may be a niche market (so to speak) but it's our niche. And the PS2Linux community website is filled with programmer types doing all sorts of things including porting programs, (Like Quake 1 & 2.) so I have some hope of getting people interested in porting a Linux based FS2 engine to PS2 Linux. Weirder things are happening all the time. (Like the Neural Net Simulator project on the PS2Linux site.)
Reality is defined by our perceptions of the world around us and our will in shaping it into what we want it to be. :)
PS If we didn't at least intend to do a Linux port we wouldn't have the Warpcore CVS, and finding alternatives could be more complicated.
-
Sure, a Linux port may be a niche market (so to speak) but it's our niche.
PS If we didn't at least intend to do a Linux port we wouldn't have the Warpcore CVS, and finding alternatives could be more complicated.
I agree compeltely. But, here's the trend I'm seeing while puttering around here
- The technical people tend to want to do the OpenGL/Linux/bells-and-whistles thing.
- The non technical people want to fiddle with the code and add stuff, and they're relying on the technical types to tell them the best course of action. They're letting themselves be intoxicated by the holy-grail-speak.
I'm just suggesting that the two are sort of incompatible. Its worth letting the non-technical types know that they should probably not be holding their breath. The Linux/GL project is an end unto itself. Its probably not the same end the simple mod-types are really looking for.
As far as VC++ being a sketchy program, well, that's just silly. Its used for everything, and I can't think of a single problem I've ever had with it, especially related to code generation. On the other hand, I've worked directly with gcc for a shipping product (Summoner PS2) and it was the personification of agony. I think you Linux types let your brains become addled by all the anti-Microsoft rhetoric out there :)
-
Originally posted by EdrickV
PS If we didn't at least intend to do a Linux port we wouldn't have the Warpcore CVS, and finding alternatives could be more complicated.
Not 100% true. Even if you didn't intend to do it, all I care is that the project allows it :) Even if that means only one or two people end up caring about that part. My main goal was to attract people who had that intent, but as you can clearly see, d3edit doesn't run under Linux. So that's not a 100% requirement, although it's certainly desireable. My biggest thing is to let a community site become a central development grounds for an fs2source project. We've hosted Descent/Freespace related stuff for a long time, and hope to continue to do so...
-
Personally, I think the first priority should be getting the multiplayer/cutscenes working, so that then FS2 is at the same level of completion that it was before. Then adding all the graphics tweaks should be done. So...
1) Get multiplayer working
2) Fix bugs
3) Get cutscenes working
4) Perform Inqui's 2, 4, and 5
-
Originally posted by daveb
I agree compeltely. But, here's the trend I'm seeing while puttering around here
- The technical people tend to want to do the OpenGL/Linux/bells-and-whistles thing.
- The non technical people want to fiddle with the code and add stuff, and they're relying on the technical types to tell them the best course of action. They're letting themselves be intoxicated by the holy-grail-speak.
I'm just suggesting that the two are sort of incompatible. Its worth letting the non-technical types know that they should probably not be holding their breath. The Linux/GL project is an end unto itself. Its probably not the same end the simple mod-types are really looking for.
Perhaps, but I work on other projects where we have lots of win32 and Linux developers, and we have things clean enough that both developers can usually develop without worrying about the other platform. So it is very possible, even in large projects.
Two projects that I work on from time to time that are good examples:
Project Twilight
http://twilight.sf.net/
GtkRadiant
http://www.qeradiant.com/
Project Twilight uses SDL for everything, which allows us to have a version of the Quake engine that runs on win32, Linux, freebsd, etc. without really hampering the development process for any developer on any of those platforms.
GtkRadiant uses STLport (a stable *imho* version of cross-platform C++ STL), GTK+ (not the best cross platform windowing toolkit but more than capable), and a lot of code.
So I'd just like to point out that it's very possible to keep multiple developers on various platforms happy while still keeping the game portable. From my discussions with other developers I don't think any can disprove the fact that writing portable code from the beginning that's as platform agnostic as possible isn't beneficial. It is very much so, now obviously in "Real Life" there are deadlines, publisher demands, and other wonderful things that don't make this ideal situation possible.
Anyway, the point is games are fun, and no one should be left out if possible and reasonable :)
As far as VC++ being a sketchy program, well, that's just silly. Its used for everything, and I can't think of a single problem I've ever had with it, especially related to code generation. On the other hand, I've worked directly with gcc for a shipping product (Summoner PS2) and it was the personification of agony. I think you Linux types let your brains become addled by all the anti-Microsoft rhetoric out there :)
Visual C++ 6.0 is a bit of a skecthy program, in that it lacks improved C/C++ standards complicance, and has some very odd math behaviors with some optimizations. However, I will readily admit that gcc is under heavy development and it has *some* of the same problems, but IMHO less. Of course at the same time VC6.0++ is now ancient in comparison to Visual Studio .NET (not that i'm enthused about the .net part).
I know for a fact that gcc (current) is far more standards compliant than MSVC's compiler, I also know that the number of *nix operating systems and servers out there that use gcc are a *huge* number. gcc is on Linux, Solaris, *BSD, *nixes and various other platforms, it is the defacto compiler outside the Windows world.
In the end, I want something to work on Windows, Linux, Mac OS X, and any other platform that it's reasonable to support.
-
Also, don't forget Intel's C/C++ compiler is available under Linux too ;) One doesn't *have* to use gcc. There's also Metrowerks Codewarrior as well...
-
WM: DOH Yeah, video :) It's in my notes :) Just was working from memory, good catch.
I'll have a sketch of a plan next week ish, if anyone cares :)
-
From my discussions with other developers I don't think any can disprove the fact that writing portable code from the beginning that's as platform agnostic as possible isn't beneficial.
Its only true in the completely idealistic sense. Writing an agnostic renderer that supports DirectX and the PS2, where the PS2 is your lead platform is going to cause you agony, period. Not all hardware and/or API likes to do what every other hardware/API likes to do. This will trip you up.
I agree with the rest of your post, but I stand by my original statement. This goal is at odds with what the majority of the people around here really want to accomplish.
-
Originally posted by daveb
Its only true in the completely idealistic sense. Writing an agnostic renderer that supports DirectX and the PS2, where the PS2 is your lead platform is going to cause you agony, period. Not all hardware and/or API likes to do what every other hardware/API likes to do. This will trip you up.
When you involve consoles, or get down to optimizations and fine tuning certainly. But writing without thinking about one specific platform to begin with should make it easier to work with multiple platforms later due to non-reliance on platform specifics. Now consoles are whole another ballgame, they're just pitiful in comparison to the PC when it comes to limitations.
I agree with the rest of your post, but I stand by my original statement. This goal is at odds with what the majority of the people around here really want to accomplish.
And you certainly have the experience to say so, but note I did qualify that this ideal situation does not always happen due to "real life" demands. However, I completely disagree that this goal is 'at odds', I believe I already documented that it is very possible to work on a large project without having every developer having to worry about the platform specific issues. I do this all the time, GtkRadiant is an iD Software sponsored development product, and we seem to have no problem (for the most part) keeping both platforms happy. Is it harder? Sure. But is it worth it? It has been for us...
(*please note that i'm not affiliated with iD Software in any way, I'm simply a volunteer involved with one of their sponsored projects)
-
Originally posted by EvilTypeGuy
When you involve consoles, or get down to optimizations and fine tuning certainly. But writing without thinking about one specific platform to begin with should make it easier to work with multiple platforms later due to non-reliance on platform specifics. Now consoles are whole another ballgame, they're just pitiful in comparison to the PC when it comes to limitations.
Lest I seem foolish, I am certainly aware that a project without a target audience, and goals will go nowhere fast, and in the publishing world *focus* is very much a necessity. Limited resources means limited support of a limited set of platforms.
-
Originally posted by EvilTypeGuy
Lest I seem foolish, I am certainly aware that a project without a target audience, and goals will go nowhere fast, and in the publishing world *focus* is very much a necessity. Limited resources means limited support of a limited set of platforms.
Heh, that's why daveb's comments about the Mac/Linux audience size didn't bother me... I'm not a publisher, I'm essentially doing this for an audience of one anyhow (me). Of course if someone else wants to play w/ it that would be cool too :)
The point is, at this point, unlike Volition and Interplay, we are not being paid to do this. No deadlines, no bosses, either, so the pressures and requirements are vastly different. We can afford to please ourselves.
-
Well this is all very interesting indeed. I thank all of you for answering questions and telling me stuff :)
There sounds like alot of enthusiasm so I am hopefull. Hopefully with VWatch and HLP trying to work this thing together we'll have some solid community support for you guys.
-
Gosh Dave, who pissed in your package of caffinated penguin mints?
People run Linux, those people want games, my friends and I work our tails off to give them games. I don't care if there are 186 Linux users or 186,000, I do it because it's fun and because I want to play games on Linux. Lighten up, this isn't a game company trying to decide how to make a profit, this is a bunch of people trying to figure out how to make a game they enjoy run where they would most like to play it. Any approach that completely excludes Mac and Linux players makes the game less fun for less people. And since no modifications anyone makes to the FS2 source now will get them any money, people are free to consider markets ignored by the original developers due to financial restrictions.
There's no publishing studio breathing down our necks, no deadlines creeping up on us, just us, some code, and some great ideas. Stifling those ideas will not get anyone anywhere.
Our Linux version of FS2 will be completed shortly. We will include source with our release. Thanks to the magic of Open Source, you guys are free to use anything that helps you out from our tree in your own. We just ask that proper credit be given.
After a release or two we will probably ignore this project. We have a lot of stuff to do and this will become low priority quickly.
Also, penguin, never use glDrawPixels/glReadPixels. That is likely why your 2D drawing is slow. Split your image into textures and draw those instead. I believe there's a nice document on it in the ZSNES source package.
-
Gosh Dave, who pissed in your package of caffinated penguin mints?
I believe you've totally misinterpreted the tone of Dave's post. And gosh, I hope maybe I've just misinterpreted your tone as well.
He is the original programmer for this code (or one of them) and he does know the industry and he does have alot of wisdom and experience to bestow on us. He doesn't have to do that...but I think he loves this game as much as we do and he's happy to see that we are trying to do something with it.
Just because he's trying to prove a point or express something doesn't mean that he's trying to bash someone else. Not at all.
-
Originally posted by theoddone33
Also, penguin, never use glDrawPixels/glReadPixels. That is likely why your 2D drawing is slow. Split your image into textures and draw those instead. I believe there's a nice document on it in the ZSNES source package.
Mmmph. OK, thanks for the tip. I'll be the first to admit that I'm somewhat of an OpenGL n00b. Once I get things a little more stable, I'll give that a shot...
-
theoddone33, there's an old saying that applies here..."Don't bite the hand that feeds you." Considering the only reason we have the source code is because dave released it, your entire post sounds extremely arrogant, especially the part about "giving credit where credit is due. So. Lighten up.
I think dave has a good point. From what I've heard, plenty of people dual-boot between Windows and Linux so they can play games, and the majority of games are for Windows. Thus, there's a larger audience that use Windows than Linux. That's not to say that a Linux port is a bad thing, but making it the sole goal of the entire project won't be as helpful as upgrading the current DirectX code.
Yes, I'm one of those "non technical" people as far as editing the source is concerned :p
-
Yes, I'm one of those "non technical" people as far as editing the source is concerned
But seemingly no less wise either :D
-
Originally posted by IceFire
I believe you've totally misinterpreted the tone of Dave's post. And gosh, I hope maybe I've just misinterpreted your tone as well.
I interpreted daveb's posts as saying "Don't waste your time on a Linux or Mac port, it's just not worth it."
If I indeed misinterpreted his point, I apologize.
-
Originally posted by WMCoolmon
...but making it the sole goal of the entire project won't be as helpful as upgrading the current DirectX code.
No one ever said it was the sole goal of the entire project. It is ONE goal of SOME of the people. Thanks to the miracles of CVS, in most cases everyone should be able to work on their own goals simultaneously as long as they do things right, keep good changelogs, and have good communication. Speaking of which, we need to agree on a changelog format, and documentation of any changes which require more than "I added this". Best to get it out of the way ASAP.
Originally posted by theoddone33
Our Linux version of FS2 will be completed shortly. We will include source with our release. Thanks to the magic of Open Source, you guys are free to use anything that helps you out from our tree in your own. We just ask that proper credit be given.
What version? You mean the one penguin was working on or something else? I'll be VERY surprised if it is done "shortly". Although I disagree with dave's apparent pessimism, I still think it'll take a while longer. Perhaps a long while longer. It might be PLAYABLE "shortly", but I have no doubt there'll be plenty of bugs to work out. There always is.
Originally posted by theoddone33
Also, penguin, never use glDrawPixels/glReadPixels. That is likely why your 2D drawing is slow. Split your image into textures and draw those instead. I believe there's a nice document on it in the ZSNES source package.
Extra thanks from me for pointing that out; since penguin mentioned the slow 2d I was trying to grasp that idea at the edge of my memory. Then I saw this, and thought "GAH! That's right! Why couldn't I remember that?!" :D
-
This goal is at odds with what the majority of the people around here really want to accomplish.
No, he's just saying that it's less likely to have as great an effect as the other things that could be done instead. :nod:
In one of his previous posts he did advise against people helping the OpenGL/Linux people, but I suspect that's so people don't flock over there just because it seems like the thing to accomplish.
-
That interpretation is wrong. But I do love how Linux people get so defensive :) We could go on and on about Linux games development for profit, but that's not the issue here.
What I'm saying is, a project of the scope this appears to be is very likely the kind of project that overdoes itself and causes all interest to be lost by 95% involved very quickly. I don't consider a straight port of the game using OpenGL as a rasterizer to be the apparent goal. What I see coming of this is some large unwieldy project with self-appointed managers dictating that the game _will_ use X, Y and Z and it _must_ be maintained across 25 platforms simultaneously, with the eventual goal of being made massively multiplayer. Maybe that's an exaggeration, but it gives you the flavor of what I'm talking about. That's what it smells like - I could certainly be wrong.
But at this point, I'm repeating myself. Bottom line, it seems to me the smartest course of action for those who simply wish to add some cool stuff to FS2 is to take the straight code as it exists and run with it. Don't worry about running it on 6 sets of hardware. Make it run for those who can already run it, and you're more likely to get results that _you_ can be proud of.
On that note, I return this thread to its regularly scheduled program.
-
Originally posted by Mysterial
What version? You mean the one penguin was working on or something else? I'll be VERY surprised if it is done "shortly". Although I disagree with dave's apparent pessimism, I still think it'll take a while longer. Perhaps a long while longer. It might be PLAYABLE "shortly", but I have no doubt there'll be plenty of bugs to work out. There always is.
This is not the version penguin was working on, this is a version done completely independantly by some folks at icculus.org.
Here is our status:
- OpenGL renderer is functionaly complete. There is still a minor bug to fix in this, and when I say minor I mean "does not affect gameplay at all." The renderer could still use some optimization.
- The only thing not complete input-wise is the joystick code, this needs another 30 or 40 minutes of work.
- Sound support is still being finished.
- We still need to add some Linux-ish features such as config saving in $HOME.
- We need to give netplay a more thorough test.
I'm not going to give you an estimated release date and time, but I don't think I'm far off when I say it will be out "shortly."
-
Originally posted by daveb
That interpretation is wrong. But I do love how Linux people get so defensive :) We could go on and on about Linux games development for profit, but that's not the issue here.
I have a lot of insight into how Linux games perform commercially, and you're right, it's "not economically viable" (to quote Falling Down) for a studio or publisher to produce games for Linux. I just do stuff so that when commercial games are ready for Linux, Linux will be ready for commercial games.
Anyway, I apologize for the misunderstanding. I now see your point: an open source game project can either go the way of Doom (hundreds of individual projects), or the way of Quake (one or two large-scale projects). I think the organization provided by the Quake way is beneficial, assuming that project managers aren't power hungry and whatnot. The benefit of the Quake way is that you only have to download one thing to get every cool feature that's been added. The benefit of the Doom way is that it's easy to add quick gameplay hacks.
As I see it, people here are trying to get the Quake way's infrastructure in place so that people can add cool features to the conglomerate engine that runs on Windows, Mac, Linux, Beos, PalmPilot, ENIAC, and whatever else. That way if you want to add your cool feature, it's available to more people, with more people's features added in already to compliment your own.
If you want to wait a couple days before adding your cool hack, use the conglomerate engine and it will be available to more people. If you don't want to wait, add it to FS2 now and when somebody adds it to the conglomerate tree your work will be overshadowed or ignored.
-
At the moment, a PS2Linux port is just a dream. :) A working Linux port I can get is needed first. With a little luck, it just might compile without changes, (SDL is available as is Mesa) but to really be playable it will probably need to be optimized for the PS2's unique graphics system. In any event, none of the work I've done with the code has had anything to do with Linux so far. I've made a fix for is_tagged, have made a FS2 version that uses a different registry key so I can test stuff in both graphic modes without having to change it in the launcher, and have been experimenting with creating subsystem subobjects that can be undestroyed. (For transformable Veritechs in the Robotech MOD.)
One thing I would really like if anyone out there thinks they can do it would be a Cygwin compatable GCC port of FRED2. :) I'm not even sure it's possible without major work to make wrappers (or something) for all that MFC code though. Without a GCC port I can't compile FRED2 which means I can't add SEXPs without outside help, unless I manage to get VC++ 6.0 at a computer show or something and that probably wouldn't happen for a couple months at least.
-
Bottom line, it seems to me the smartest course of action for those who simply wish to add some cool stuff to FS2 is to take the straight code as it exists and run with it. Don't worry about running it on 6 sets of hardware. Make it run for those who can already run it, and you're more likely to get results that _you_ can be proud of.
Which is basically what I think people like myself would like to have. We just want FreeSpace 2 to run a little quicker or a little cooler or with some kind of added elements that we didn't have before.
I think that the Linux thing is definately cool and I hope that it can all be worked out...I just want the next project I do around here to be able to take advantage of the source and add some new things that will help me tell a story and have some fun in missions.
-
Which, unless I am grossly misunderstanding the modular nature of this code, is not really an issue.
There are an awful lot of feature requests to sift thru, lets see what we got. The "little bit cooler" part IS being attacked, I'd like those attackers to get write access to the CVS as well.
There's plenty of work to interest everyone, and I personally don;t see how one group of people working on a port can affect another group of people writing cool new sexp's or adding beams to fighters, or whatever :)
THta's the beauty of a project like this :)
That being said, sounds like maybe theoddone is making some of the porting excercise superfluous by being almost done.
Guess we'll wait and see for that, unless he wants to share before release :)
-
fs2_open - the Linux/OpenGL port (aka "the penguin build") is up on Warpcore's CVS -- thanks Inquisitor! :yes:
From the README:This is very much an pre-alpha build. Don't expect too much from it!
It is very incomplete, crashes often, is slow, has lots of debug printfs, has no configure nor install scripts... I could go on and on.
I am actively working on it, but if theoddone33's build is much farther along, or is obviously better, I will gladly defer to him :)
Brief status: 2d is done (but will need to be reworked as it is very slow), 3d rendering is about 75% done: no textures, so it looks like you're fighting a bunch of gray ghosts! No sound, no joystick, no network.
In other words, if you're very curious, go ahead and download it and play around with it. Otherwise, I recommend that you wait for a more stable build...
-
Originally posted by theoddone33
This is not the version penguin was working on, this is a version done completely independantly by some folks at icculus.org.
I'm not going to give you an estimated release date and time, but I don't think I'm far off when I say it will be out "shortly."
Well of course I meant penguin's version wouldn't be done shortly. I couldn't know how far that one is.
Is it a source modification or did you build it from the ground up?
-
Which, unless I am grossly misunderstanding the modular nature of this code, is not really an issue.
There are an awful lot of feature requests to sift thru, lets see what we got. The "little bit cooler" part IS being attacked, I'd like those attackers to get write access to the CVS as well.
We should probably try and establish something to help you guys sift through all the requests. I know in the documents for my new project I have a number of items I'd like to suggest and I bet others have that too.
-
Originally posted by Mysterial
Well of course I meant penguin's version wouldn't be done shortly. I couldn't know how far that one is.
Is it a source modification or did you build it from the ground up?
It's a modification of the public source obviously. I'm somewhat disappointed that icculus.org people got involved with a port, it's kinda cheating ;) (Some of them are previous Loki Games employees which means it was almost trivial for them to port it =p (In comparison to other people doing it)) But, looking at the difference between the two code bases will certainly help quite a bit learning wise for a lot of people...
-
Originally posted by EvilTypeGuy
It's a modification of the public source obviously. I'm somewhat disappointed that icculus.org people got involved with a port, it's kinda cheating ;) (Some of them are previous Loki Games employees which means it was almost trivial for them to port it =p (In comparison to other people doing it)) But, looking at the difference between the two code bases will certainly help quite a bit learning wise for a lot of people...
Cheating is a good thing if it gets a playable game out sooner ;7
You use what you got -- as I've said before, I'm kinda new to OpenGL programming (and game development in general) -- most of my real life stuff is much less exciting :blah: So if there are people who actually know what they're doing that are working on this, the end result will be better for all involved. It will be interesting to see how this all works out...
-
This is probabily jumping the gun quite considerably, but I was thinking.... Whilst it's all well a good being able to play Freespace in Linux, but since it has a windoze installer, you wouldn't be able to install it without either wine, or a Windows install. So I've been thinking about creating an installer using Loki's setup tool.
Now the snag. The files are contained within Installshield's .cab files which are different that Microsoft's. Net result. You can't decompress the files without a rather handy extraction utility which is only available for win32. The upside. source code is available. Downside... I know nothing about C so I can't port it. If anyone's bored, has 20 minutes free and would like to give me a hand with this, let me know. It's only a small program, and shouldn't take too long (if of course it's possible)
-
Where's the source to the extraction utility located?
-
I've found it in many places... one such place is ftp://ftp.sac.sk/pub/sac/pack/i5comp21.rar
-
One side note to a Linux build: Might generate a Linux server, which, for anyont who has run the current dedicated servers, knows is a bit of a bugaboo.
Thanks to penguin for uploading his source to CVS, now to figure out what Iscrewed up when I made his account the first time :)
-
The ps2_open version won't build on non-x86 Linux. There's a little bit of assembly in windows_stubs/stubs.cpp in MulDiv(). Compiled with less warnings then the GCC Cygwin port until then though. Shouldn't be hard to replace that bit of assembly with C/C++ code, if you know what it's supposed to do. :)
-
Originally posted by EdrickV
There's a little bit of assembly in windows_stubs/stubs.cpp in MulDiv(). Compiled with less warnings then the GCC Cygwin port until then though. Shouldn't be hard to replace that bit of assembly with C/C++ code, if you know what it's supposed to do. :)
Heh, it's pretty simple, I shoulda put a C version in if the arch is unknown. Next patch :) It never occurred to me that anyone would try to build on non-x86 this early in the game. Shoulda known :o
Is this for the PS2? What processor does it have?
Edit: added C version, will use asm if i386, else the machine-independent code.
-
The PS2 uses a modified MIPS 5900 along with it's specialty processors: The VPUs VPU0 and VPU1, the custom graphics system, and lots of other oddities. (VPU0 by default acts as a co-processor for the 5900.) Will try and update that version so I can try compiling it more. :D (I doubt it'll run, at the very least due to screen resolution problems, but since I can get the source I want to try compiling it.) I've been trying out all sorts of stuff, and a lot of it's not working very easily. Some things just need a ./configure --build=mips-linux, like XMMS. And some things, like the Xvnc server, (not the client) seem to need some configuration editing.
-
I actually got it compiled! And it tried to run! But then it segfaulted:
Setting language to English
soundcard = (nothing)
No video card defined... exiting
GR_CPU: Family 0, MMX=No
Initializing opengl graphics device...
Screen BPP: 16
Vendor :Brian Paul
Renderer : Mesa X11
Version : 1.2 Mesa 3.3 beta
Extentions: {big list of stuff}
Fatal signal: Bus Error (SDL Parachute Deployed)
GL User Error: calling glScissor without a current context
GL User Error: calling glClear without a current context
Segmentation fault
That was from being run by a terminal in X running on a TV at less then 640x480 resolution. When run from a console it was complaining about not being able to get a big enough display. Might work differently from a monitor, then again it might not. But it actually popped up a window for a sec! :)
-
Did you install the SDL RPMs?
And getting it to compile is a big deal :)
-
PS2's not gonna like 640x480. You're gonna need to use 640x448 or 320x224. But hi-res/lo-res have kind of "special" meanings on TV sets. Its possible the OpenGL implementation has stuff to deal with this. _But_ you'd be really short-changing yourself if you just stuck with OpenGL on that beast. If you do, what you end up with is a marginal GL implementation running on a pretty craptacular CPU. All the "fun" of the PS2 comes from writing PS2-specific code. Get cozy with the EE-User's manual (specifically, the DMA and VIF chapters), the GS User's Manual and the VU User's Manual. Making the PS2 architecture hum is a fascinating experience.
-
Originally posted by EdrickV
I actually got it compiled! And it tried to run! But then it segfaulted:
Very cool :yes:
SDL and OpenGL are getting initialized, it looks like...
The bus error looks like the culprit -- most RISC architectures are much more picky about word alignment than the x86. My guess is it was trying to read an int out of a structure that was not 4-byte aligned. Might be way ugly to find (and worse to fix)...
Have you tried running it under gdb? A lot of times when you get a bus error the stack is useless, but you might get lucky and find where the error occurred.
-
Under X FS2 could actually create a 640x480 window, I just wouldn't be able to see all of it at once. My virtual desktop's total size is 1156x808 (578x404 *2)and I can pan around it. PS2Linux can work with a sync-on-green monitor and get better resolutions (640x480, 800x600, 1024x768, and maybe higher) and HDTVs and get the special resolutions they provide. I didn't expect it would run on a TV without major editing. :)
SDL should be installed, I'm not completely sure it's installed right but I will look into that. I'll also see what I can discover with gdb. I do know the PS2 is not a bigendian system, unlike most MIPS systems. (It has the same endianness as a PC.)
-
I think it is *not* an SDL or OpenGL problem -- it always runs in windowed mode (for now), so if you're seeing the above messages, and a window is popping up on the screen (however briefly), then I think the SDL is getting initted OK.
The problem is probably deeper within the code, my guess is still accessing some misaligned int. The endianness doesn't really matter -- some architectures are just a little more picky about how 16- and 32-bit values are aligned. The x86 family is very lax.
Send me a PS2 and the kit and I'll be happy to debug it :nod: :D I'll even pay for shipping ;)
-
Tried using gdb and, while I'm not totally sure I'm using it right, I'll post what I got from it:
Starting program: /home/Hunter/games/freespace2/fs2
Size of bitmap info = 1121 KB
Size of bitmap extra info = 8 bytes
WARNING: "Cannot chdir to /home/hunter/games/freespace2: No such file or directory" at windows_stub/stubs.cpp:103
Building file index...
Found 5 roots and 6872 files.
==========================================================================
DEBUG SPEW: No debug_filter.cfg found, so only general, error, and warning
categories can be shown and no debug_filter.cfg info will be saved.
==========================================================================
Opened fs.log OK
Setting language to English
soundcard =
No video card defined... exiting
GR_CPU: Family 0, MMX=No
Initializing opengl graphics device...
Screen BPP: 32
Vendor : Brian Paul
Renderer : Mesa X11
Version : 1.2 Mesa 3.3 beta
Extensions : GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_logic_op GL_EXT_blend_subtract GL_EXT_paletted_texture GL_EXT_point_parameters GL_EXT_polygon_offset GL_EXT_vertex_array GL_EXT_texture_object GL_EXT_texture3D GL_MESA_window_pos GL_MESA_resize_buffers GL_EXT_shared_texture_palette GL_EXT_rescale_normal GL_EXT_abgr GL_SGIS_texture_edge_clamp GL_EXT_stencil_wrap GL_INGR_blend_func_separate GL_ARB_multitexture GL_NV_texgen_reflection GL_PGI_misc_hints GL_EXT_compiled_vertex_array GL_EXT_clip_volume_hint GL_EXT_texture_env_add GL_ARB_tranpose_matrix
Program received signal SIGBUS, Bus error.
warning: Hit heuristic-fence-post without finding
warning: enclosing function for address 0x5f766e65
0x5f766e65 in ?? ()
Tried setting the fence post thing to 10 and ran it again. I got the following difference:
Program received signal SIGBUS, Bus error.
Cannot access memory at address 0x5f766e62
What this all means I can't even guess. :)
Addendum: And the window it made (which hung around with gdb long enough to "identify" it) was an SDL_app window. Or something like that. Interesting thing is, if this ever works on PS2Linux it looks like we could use a display on another computer through the standard X server/client stuff. (The results of running fs2 using my PC as an X server and the PS2 as the client were the same as on the PS2.)
-
penguin: I'll happily let you telnet into mine :)
-
Originally posted by Inquisitor
penguin: I'll happily let you telnet into mine :)
That's NOT what I asked for, please read my post above if you're still confused :D :D :D
Actually, I may take you up on your offer, but we had a server failure last night (RAID card got cooked) and I got about 3 hours sleep, so I don't plan on doing much FS2 for the next 24 hours :sigh:
-
Hehe, maybe so, but that's the best I got :)
Bummer on the no sleep, go take a nap and stop responding to threads :)
-
Almost working on a PS2? :eek: :eek: :eek: :eek:
-
Almost working with just about everything but graphics disabled, but likely far from playable. :) (As Penguin's always saying, code optimization can wait till everything works.) Hopefully the other group will release theirs soon and put it up so we can check it out. :D I know some stuff is kinda stubbed out (like all the registry stuff) with empty functions and TODO comments. And other stuff is ifdeffed out. Still, the fact that it compiled and tried to run is cool! :cool:
-
Nope, it's not finished, but here it is:
http://www.icculus.org/~relnev/freespace2-020605.tar.gz
Hope this helps!
Steven Fuller
-
Thanks relnev, just wanted to take a moment to thank you for all your porting work :) You do a *LOT* of ports. Your work is helping me learn a lot more about graphics! Thanks!
-
Little update:
The Incculus.org version won't just compile with GCC 2.95. (It expects G++-3.0.) With 2.95's G++ it complains about anonymous structures so I think I'll have to download GCC 3 to try compiling this one. :)
-
BTW, i've imported the icculus.org version into CVS on warpcore.org for thsoe who care to browse it:
http://fs2source.warpcore.org/cgi-bin/cvsweb/cvsweb.cgi/fs2_icculus/
Thanks again relnev...
-
GCC 3 is on the ps2linux community site I think, isn't it? Or are you talking about the vanilla x86 compile?
And thanks for the link relnev, looking forward to looking at it :)
-
Yup, GCC 3.0.3. Over halfway downloaded. And for some reason it didn't seem to need me to download this file using SSL.
-
wow... that's all I can say.... looks damn good... very good FPS on my box... no sound at all thought, but that's because I did have to comment out a section in one of the files (I forget which) that had some sound stuff in it, in order for it to compile. Most likely a problem with OpenAL, which I just downloaded the debian package for. Anyone here been able to get it to compile out of the box using Sid?
-
if you need it non ssl, lemme know, I'll toss it up on a website for you
-
What I meant was: A while ago when I tried to download the kernel source with GetRight it didn't do it because it wanted to use https which GetRight doesn't support. I had to download it using IE which meant no pause/resume. Now, for some reason, I can download GCC 3 with GetRight. (That's a good thing.) Wonder if it was a system wide change as I haven't tried downloading other programs with GetRight lately.
-
Well, GCC 3.0.3 got a bit farther, but ran into some assembly that wasn't taken out. So this version won't compile on PS2Linux without modifications. (I believe the file was aaline.cpp, and there may be more.) May see if it'll compile under Cygwin later, if I get GCC 3 for it.
Now to see if I can get Wings3D working. :D