[dizzy]

Hi there

I noticed that "make tools" fails on scramble. Partly because scramble does not include "pstypes.h", partly because it does not link to codes that provide vm_malloc & friends. I noticed these are defined in windows_stub/stubs.cpp but man, hell is brake loose in there, that file needs a LOT of reorganizing. Anyways, please consider the following modification: to move vm_malloc & friends in their own file (still in windows_stub) so we dont have to link scramble against SDL (because stubs.cpp uses SDL functions) for the vm_malloc stuff. Also I noticed some other things that could be improved in that file:
- Delay() : why use SDL_Delay() ? POSIX.4 gives nanosleep(), most UNIX systems give usleep() and I for one would not use any of those but instead I would use select(1, NULL, NULL, NULL, ) (no, it is no joke, select() like that can be used as a portable delay function, it works even in Win32 , yeah ok, there you have Delay() too); also I think the comment in there is misleading ("non-blocking process pause", huh ?? is as blocking as it gets )
- timer functions: I think those should use POSIX setitimer/getitimer for those; ok I have not digged enough to see how exactly those timers interact with the rest of the codes but it's an idea

In general about all this "stubs" I think a better solution then trying to offer exactly the win32 API is to see for each function that needs portabilty what is the needed use by FS2 codes (like for timeSetEvent() if it needs all those arguments or not, fuEvent seems ignored to me), then make an API to allow that functionality (so instead of timeSetEvent(delay, resolution, timeproc, user, event) you would have addTimer(delay, timecb) because only those seems to me are needed/used by FS2) then implement that API for different supported systems using the underlying system dependant support. And also, I would do all this in it's own namespace, "os" sounds like a good namespace for those

Anyways, I too hate people that talk more than they code So, if you like my ideas please say so, so I can make some patches.

Thanks!

[taylor]

Yeah, scramble is fubar.  I did fix the problems but never put them in cvs, cause I don't care.  It has no use for vm_* stuff so it just needs to go back to using the standard malloc/free.  I actually never meant to make that change but forgot about it during commit of the vm_* changes.  But if you want to send a patch for the scramble stuff please feel free.  I don't really want to go through all of my experimental code trees to figure out which one has the scramble fixes.


- SDL_Delay(), because I don't want to #ifdef the hell out of the thing.  It will use nanosleep() or whatever works best on the platform it's running on.  Leave it to SDL, saves on code for us.
- timer functions, there are too many freaky issues there and as long as it works then it will likely get left alone.  What we have works well for what it does and setitimer won't give us any extra precision over the current method(s).  The Windows specific timer code will probably get dropped if we go with SDL since the two are doing the exact same thing.

The stubs work because it's been easier to deal with for everyone.  It keeps as many ifdef's out of the code as possible and while it can get a bit useless with Linux code it can be dealt with pretty easily.  Eventually we'll probably go with SDL on all platforms so most of that will be rendered obsolete.  We can get rid of all of those extra types and use what SDL provides us and remove most of the platform specific code.  That's for the future though.  All of the cross platform stuff is going in stages and this particular cleanup stuff is really at the end of that chain.  Audio->Input->Video->EverythingElse, that's pretty much how it will go.  Audio won't use anything SDL at first and neither will the input changes (but will be ifdef'd).  Video will go with SDL (after some public testing) for initting/controlling OGL on all platforms and that's the first time that SDL will be a requirement.  Audio and input code will then be compiled to use SDL by default.  OS stuff and types will come later.

[dizzy]

I see. Yes, going for SDL if it offers all you want and is portable enough sounds like the best way. Had no idea about the future plans of the project so I guess my sugestions in this respect are kinda useless now

Oki then I'll see about scramble and if I got some more time (not just an hour or so) look into that VP archive library project I intend to work on. As I said in another thread this should also be possible to be used later in fs2_open codes to cleanup the cfile stuff. Please have a look on this thread when you got the time, thanks!

http://www.hard-light.net/forums/index.php/topic,34871.0.html

[taylor]

Originally posted by dizzy
Oki then I'll see about scramble and if I got some more time (not just an hour or so) look into that VP archive library project I intend to work on. As I said in another thread this should also be possible to be used later in fs2_open codes to cleanup the cfile stuff. Please have a look on this thread when you got the time, thanks.

I'm pretty sure that WMCoolmon is already working on a VP utility/lib.  I don't have a link to it handy though.  Cross-platform (may need endianess checks???) but can view/add/remove/insert files in a VP.  It cmdline only and though I could be wrong, I think he was making a lib out of it for later use in a GUI.  cfilearchiver was an original Volition utility that was released with the code.  cfileextractor was just something quick and dirty by me to fill a need to extract VPs on non-Windows systems.  WMCoolmon has a better and more long term solution so hopefully he'll get the time to finish it up.

I'm not too sure about rewriting CFILE in the game to a C++ interface but I don't have anything against that either.  It will get some rewriting and major cleanup when I get the time to finally implement support for CVPs though.  If you want to rewrite it I'd probably wait until after that gets committed.  No real estimate on when that will happen though since the new audio code, movie code, pilot code, options code, input code, ini code (replaces registry under Windows), and cross-platform launcher come first.  What else ya got.

[taylor]

Here is the current wish list if you are interested in any of these things (no particular order):

• Stand-alone server mode for Linux and OSX.  This needs to be the regular binary if possible and only some sort of controllable interface is needed to make it work.  No real requirements on how best to do it but it's preferrable to have no new build requirements.
• Rework audio capture code to be cross-platform, or add Linux/OSX support.  This is needed for real-time voice support which would be very nice for multi play.  It currently uses DirectSound so when we move to OpenAL this will cease to work and an alternative is needed.
• Debug the 3D positional audio code for OpenAL.  Most of it should be there but is disabled by default.  It's a bit hacked up since I tried a great many things to get it going properly so some of what's there may need to be completely redone.
• Text-to-speech support.  I started this but didn't really like how little control I had over the output and couldn't find any real docs or examples on how to implement it well.  The interface was /dev/speech so that no new API is actually required or forced as a dependancy.  I had started to redo it with festival but I really don't want to go that route if I can help it.
• EDIT: PCS2 needs some cross-platform work.  I had started to do it but I have too many other things that need more attention right now.  There are several things which are Window centric and so need to be fixed up with some platform specific functions.

That's about all I can think of off the top of my head but I know there was one or two other things that we needed as well.  I'll update the list when I think of them.

[dizzy]

Oh, thank you very much. If I may make a sugestion, there should be such TODO items in some TODO file for wannabe coders like me

The first item from your list at least looks very sexy to me (as in something that I have a lot of experience - ie network programming -, and something that I like to do - ie network programming -).

I would need some background information about this standalone server. Right now fs2_open has such a server ? But only for Windows ? I guess in that case I sould probably just focus on making it portable right ?

[WMCoolmon]

Network code has massive stability issues, that would be a good place to start, although a better standalone server would be nice too.

Something else network-related that would be very nice is in-game joining...there's a chunk of code in there that relates to it, with barely any modifications I was able to have people join in-game a couple times...but only under very specific conditions and with a certain amount of luck involved.

[taylor]

Originally posted by dizzy
I would need some background information about this standalone server. Right now fs2_open has such a server ? But only for Windows ? I guess in that case I sould probably just focus on making it portable right ?

The Windows version of the standalone server is in code/network/stand_gui.cpp and uses MFC.  The Linux version is just an empty shell of that file.

Basically, standalone server mode is the same game binary but run with a cmdline option which puts it in a different internal state (all of the "Is_standalone" references).  So really the game can already do what needs to be done.  What's missing is a way to control it.  Whether that is something that is a copy of the Windows version or if you go a completely different way is up to you.  I think it would be better to go the different way and just replace the current Windows GUI.  Different could be something java based, or better yet, web based.

And like WMCoolmon said, the network code is crap.  No one wants to touch it and it's not documented worth a crap.  There are big packet size issues, limits problems as we start going with dynamic ships and weapons tbls, plus it's just massive.  I don't think anyone is even sure what traffic goes over the wire or how much of that is really needed.  There is still IPX code in there but that could probably get ripped out at this point and we just stick to TCP/IP.  If you like networking code then it's all yours, nobody is going to stop you, or even offer to help for that matter.

A TODO list would be great, but someone has to maintain it.  It would probably be better if we just put things like that in Mantis under a special "TODO" category.

[Kazan]

Originally posted by taylor

• EDIT: PCS2 needs some cross-platform work.  I had started to do it but I have too many other things that need more attention right now.  There are several things which are Window centric and so need to be fixed up with some platform specific functions.

i was going to do this myself once i got there -- what spefically in PCS2 is breaking on linux [besides the fact that i don't think I have even done makefiles yet ]

[taylor]

Originally posted by Kazan
i was going to do this myself once i got there -- what spefically in PCS2 is breaking on linux [besides the fact that i don't think I have even done makefiles yet ]

If I have write access to the CVS tree (I think I do?) then I'll just commit the Makefile and #include line fixes.  You can work out the C++ errors after that and I'll try and replace the Windows only things when I get the chance.

[Kazan]

You registered an sf.net account and I added it to the project right? if so then you have write access

[dizzy]

Oh... can you guys just let me know if I should checkout that project and add autotools or not ? I mean I see Taylor is working on something, if it's something else then just let me know when you have commited the changes to checkout latest version, thanks!

[taylor]

Originally posted by dizzy
Oh... can you guys just let me know if I should checkout that project and add autotools or not ? I mean I see Taylor is working on something, if it's something else then just let me know when you have commited the changes to checkout latest version, thanks!

I'm just using a simple Makefile for PCS2 at the moment and have no real plans to do anything else.  If Kazan wants to go with automake and friends then you are welcome to do that.  I do think that autotools would be a better option than my plain Makefile since we'll have to make sure that the wxWidgets dependancies get worked out.

When it's working under Linux I'll go through and add endianess stuff (if Kazan isn't doing that already) and make an Xcode project for it too.

[Kazan]

taylor: since you know endianity issues much better than me i'll let you do that