Homesource Forums

Homeworld Source Editing Talk
It is currently Wed Aug 16, 2017 10:16 am

All times are UTC - 5 hours




Post new topic Reply to topic  [ 35 posts ] 
Author Message
 Post subject: Opening Pandora's box
PostPosted: Tue Apr 22, 2008 2:05 pm 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
For those of you that might have missed my introduction message I thought I would start a new thread here to let you all know that I am trying to port Homeworld to the Pandora (http://www.openpandora.org/).

No need to say it, I'm mad :twisted:

First I'm going to port the HW engine to openGL ES 2.0. I've got the PowerVR SDK installed now and have started looking through the HW code... nice to see that all the openGL stuff is in one easy to modify file :P !

Then is' just the "simple" matter of cross compiling for ARM Linux, no problem right ??
:wink:

Well, guess I better get on with it. I'll post any updates, complainant's and mad ramblings on this thread so folks can see how far (or not) I've got.

E.O.F.


Top
 Profile  
 
PostPosted: Sun Apr 27, 2008 12:54 pm 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
Hmm, the more I grep through the code the harder this task is looking. The Homeworld code extensively uses glBegin/glEnd and glPushMatrix/glPopMatrix which are not available in OpenGL ES 1 or 2 and as their is no fixed pipeline in OpenGL ES 2 I'm going to have to learn fragment shaders.

So change of plan! First try to cross compile homeworldSDL with a SW implementation of OpenGL, the Pandora has a 500MHz ARM which will hopefully be enough to do SW render. Then learn more about OpenGL & OpenGL ES 2 and "port" (or rewrite) all the different rendering parts of HW.

E.O.F.


Top
 Profile  
 
PostPosted: Sat May 03, 2008 11:33 am 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
Devil thy name is ETG :evil: !
I knew it was going too well. I managed to cross compile SDL & klimt (openGL SW lib) (http://studierstube.icg.tu-graz.ac.at/klimt/) and after a small problem compiling the KAS2C tool for ARM and then trying to run it on x86 and fixing a macro problem I was compiling HW!

Then my compiler hit ETG.c and stopped dead. So I am looking into ETG.c and am trying to find out just how deep this rabbit hole goes. I see that the MACOS port followed the same hackery as the x86 version. I have several problems which I think stop me going down the hackery road:

1) I don't like hackery :P
2) ARM doesn't use just stack or registers to pass arguments but a mixture of both (just to make it harder).
3) Not all ARMs have floating point units and the registers that go with them, this is normally left to the compiler and C library (soft-float or hard-float) to worry about.

Ah well, I should have known this wouldn't be easy, nothing really worth doing is :(. Back to it! I'll let you know if I see a little girl or white rabbit down here!

E.O.F.


Top
 Profile  
 
PostPosted: Sun May 04, 2008 9:42 am 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
It compiles!!!

After a lot of hackery of several C files & makefiles I've managed to get homeworldSDL to compile :D.

I created a load of function pointers to get around the problems I was having in ETG.c, now I just need a platform to run the binnary on :/. I have access to an ARM11 platform with 800x480 display at work which I can test it on, but that would mean I would only be able test at work. I do have a GP2x which has a 200MHz ARM9 which I could try to test on, but it only has a 320x240 display and I don't think that HW will want to run at that resolution.

Anyway, it's good to get this far :)

E.O.F.


Top
 Profile  
 
 Post subject:
PostPosted: Mon May 05, 2008 2:07 am 
Offline
coder

Joined: Wed Nov 15, 2006 8:15 am
Posts: 100
Congratulation,

Indeed, it is not an easy task to port an old piece of code such as homeworld.
I hope the binary will work for you. Keep us updated!! :)


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 06, 2008 9:08 am 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
After creating a root filesystem I tried to run homeworld on my ARM11 system:

Code:
 ./homeworld
      42 files found in Update.big
   13851 files found in Homeworld.big
SDL_GL_LoadLibrary(NULL): No dynamic GL support in video driver
SDL_GL_LoadLibrary(NULL): No dynamic GL support in video driver
Fatal Error: Couldn't initialize default rendering system
.Error creating window


:D, looks very promising, further investigation underway!


Top
 Profile  
 
PostPosted: Tue May 06, 2008 3:07 pm 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
How confusing is this:

klimt uses SDL as it's backend for rendering.
homeworldSDL uses SDL to access openGL functionality (create context, swap buffers, etc).

This means that I need to implement a hook for SDL to access klimt which will then call back into SDL :? . Who does what for the initialisation???

E.O.F


Top
 Profile  
 
PostPosted: Thu May 08, 2008 4:39 am 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
I think I know what I need to do now, I've started implementing the hooks in SDL for klimt. All being well I should have something to test Monday :).

E.O.F.


Top
 Profile  
 
PostPosted: Sun Jun 08, 2008 2:37 am 
Offline
Site Admin
User avatar

Joined: Tue Dec 14, 2004 12:41 am
Posts: 326
The following posts occurred during the smf trial period, and I'm including them here under my login for completeness and continuity.


basicmark wrote:
It;s been a while so time for another update :)

I'm moved my porting effort onto my GP2X for the moment as I can work on that at home. I've managed to get as far as HW starting up OpenGL through SDL and it seems to segfault in SDL loading libGL.so shared library. I'm currently creating a few simple test programs to see if my integration of the klimt is OK, my hope is it's just that the HW build is picking up the wrong dynamic library loader (libdl.so). Work has been a bat manic so progress is slow :(. On the plus side I've got HW to run on my new ASUS Eee, which even picks up the right screen resolution (800x480) so hopefully it will do the same on the Pandora :D.

E.O.F


Lightkey wrote:
I still doubt this will work as there is no Linux 3D driver for the graphics chip.



basicmark wrote:
There is a Linux driver for the 3D graphics IP block.
Also to start with I am using the Klimt SW 3D rendering library so don't need it :).

E.O.F


Top
 Profile  
 
PostPosted: Sat Jul 12, 2008 10:04 am 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
Just thought I would post a message to show that I'm still here :).

I haven't had much time of late to progress due to work and now going on holiday :D. As I'm hitting various issues with trying to integrate SDL with klmit I think that I might take a step back and first test my changes around ETG on a Linux PC build first as at least then I can prove that they work and push the changes back into SVN :). Hopefully once I'm back from holiday I might have some more time to spend on this, I'll keep you posted.

E.O.F.


Top
 Profile  
 
PostPosted: Mon Aug 25, 2008 4:38 am 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
Progress!

My CPU agnostic implementation of etgCallFunction is mainly working now. I think all fixed functions are OK but etgCreateNewEffect(?) which is var args still needs some fixing. I get as far as trying to destroy the 1st set of test drones in single player.

This is all on the PC a.t.m. but soon I will order a Beadgle board and when I'm happy the changes work on the PC I'll move over to using X11 and the mesa 3D lib on the Beagle to make sure my fix is really CPU agnostic. When I put the code back into svn maybe someone with a Mac could check that it also works on that :).

E.O.F.


Top
 Profile  
 
PostPosted: Wed Mar 25, 2009 6:10 pm 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
I'm finally restarting "ProjectHomeworld" :)

I decided to take a different approach this time and used macro magic to create a wrapper for all the functions called in etgFunctionCall as to would be a lot cleaner and also faster then my previous method of encoding the function prototype in the etgFunctionTable table and using it to cast the function pointer to the correct type in etgFunctionCall.

After a couple of evenings work it was going so well, that was until I found that the "function prototypes" in etgFunctionTable most of the time don't reflect the function prototype of the called function, WHY!!! ahhhhhhhhhhhhh!!!!!!!!!!!!!!!!!! **sobbing on the floor** :evil:

ETG 5
basicmark 0

"Never give up, never surrender!" - Commander Peter Quincy Taggart (Galaxy Quest)


Top
 Profile  
 
PostPosted: Mon Mar 30, 2009 5:27 pm 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
Progress at last!

Now all the etgFunctionCalls are going through a wrapper layer. I've played though level 1. Scuttling the ships at the start doesn't crash anymore (was a bug in my wrapper for etgCreateEffects.
At the moment all the args are passed as udword so I need to fix it to use the conversion functions so the function prototypes match the functions they call, which should hopefully mean it works on CPU's like the PPC that pass float args in different registers. Also need to remove the stack pushing and poping it does before executing a etgCodeBlock to check that all works OK.

Once I've done that I'll do a bit more testing on the PC and then try building it for the Beagleboard (http://beagleboard.org/) which has the same SoC as the Pandora.

Thanks to aunxx for his work on 64 bit as I've nicked some of his code :wink:


Top
 Profile  
 
PostPosted: Tue Mar 31, 2009 4:52 pm 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
Function pointers now do the right things with floats so my mods should work on PPC. Also removed pushing and poping in etgEffectCodeExecute and it's still OK. Tested level 1 & 2, part way through 3.

I think the next step is to try cross compiling. As the beagleboard runs X it should be easier then last time (here's hoping ;)). If I can get it working with mesa SW render then I'll be very happy, after that it's looking at the nanoGL wrapper (allows OpenGL games to run on OpenGL ES 1.1 GPUs) that has been used on all the Quake ports so I can use the 3D H/W.

Not got much free time over next week to work on this, but I'll keep posting when progress is made :) (or even if it isn't ;))


Top
 Profile  
 
PostPosted: Tue Mar 31, 2009 9:05 pm 
Offline
coder

Joined: Wed Oct 01, 2008 2:55 pm
Posts: 103
Location: Michigan
let me get this strait... you have some kind of c-only version of etgFunctionCall? how on earth did you accomplish this? and what does it look like?


Top
 Profile  
 
PostPosted: Wed Apr 01, 2009 2:44 am 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
Axcess wrote:
let me get this strait... you have some kind of c-only version of etgFunctionCall? how on earth did you accomplish this? and what does it look like?


That's right and (so far) it seems to work, although it's far from pretty :).

I'll refresh my patch tonight and put in in pastebin or some such so you can see what I've done.


Top
 Profile  
 
PostPosted: Wed Apr 01, 2009 3:28 pm 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
As promised a 1st stab patch can be found at http://pastebin.com/m77a8bb09. I would be very interested on seeing how this behaves on a PPC, but it might be best to wait until I've cleaned it up and checked it into SVN.


Top
 Profile  
 
PostPosted: Wed Apr 08, 2009 4:59 pm 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
In order to get a binary to test I gave up on autotools and got my hacksaw out :twisted: and I now have something to test. As it's late and my kit is not setup I'll try the binary at work tomorrow, I'm sure it won't work, but what the hey!

So I need to got back and fix some issues in auto-tooled files so I can build properly and then debug homeworld on the beagle. So back to it after the break!

Out of interest has anyone built/tested homeworld for "raiders retreat". In the end I would like to package up a H/W demo for the ARM so people who don't have the homeworld CD can play with it.

I'm also not sure about redistributing the binary I build. The Relic licence talks about redistributing to only those in the RDN, does this mean only the source or binaries as well? As much as I want to get this work out there I'd rather not piss off Relic (or appear in court).


Top
 Profile  
 
PostPosted: Thu Apr 09, 2009 10:51 pm 
Offline
Site Admin
User avatar

Joined: Tue Dec 14, 2004 12:41 am
Posts: 326
basicmark wrote:
I'm also not sure about redistributing the binary I build. The Relic licence talks about redistributing to only those in the RDN, does this mean only the source or binaries as well? As much as I want to get this work out there I'd rather not piss off Relic (or appear in court).


We have assurances and public statements from Relic that redistribution of both modified source code and binaries is OK and is in fact what was intended from the beginning.

It's just that the RDN source license for Homeworld was not... hmmm.... was not intended to be as draconian as the legalese ended up making it.

Both Homeworld SDL and Homesource redistribute both modified code and binaries therefrom to non-RDN members. (last binary release was... when?)


Top
 Profile  
 
PostPosted: Fri Apr 10, 2009 3:49 am 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
Thanks zapkitty. I didn't think it would be a problem, but just wanted to make sure.

Not that mines ready yet, but do we have somewhere to upload binaries?

I tried the binary I built but SDL didn't seem to want to open libGL (even after installing it :)), so I need to debug my setup. Before doing that I'll try and get my autotools changes done correctly.


Top
 Profile  
 
PostPosted: Fri Apr 10, 2009 4:05 pm 
Offline

Joined: Sun Apr 05, 2009 11:56 am
Posts: 8
Location: Chicago, IL
hey basicmark, just want to say that you're doing great work here and looking forward to see the results!


Top
 Profile  
 
 Post subject: It's alive!!!!!
PostPosted: Sun Apr 19, 2009 1:27 pm 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
After fixing some issues with X and mesa on my beagleboard I got glxgears to run so just for a laugh I thought I'd try my homeworld binary, and it ran :D !

OK trying to get a 600MHz ARM to render a 1024x768 image is asking for a low frame rate, but it does draw things.

http://yfrog.com/53homeworldonbeaglep

You'll notice that plant looks all wrong and what you can't see is that the menu's and text are completely foobared, but this isn't anything to do with my homeworld port, I've seen the same issue using the same version of mesa on my x86 laptop, the swraster is somewhat buggy :/. If it's not too hard I might look into building a later version of Mesa which will hopefully have these issues fixed.

I did the test of scuttling my ships which with my old code used to crash homeworld and it survived. I might try running it in QVGA mode windowed and see if it's playable enough to test. At the moment the beagleboard is mounting it's rootfs over NFS so I will need to copy the rootfs to the SD card so I use my USB keyboard and mouse as it doesn't want to play ball with the vnc mouse :/ (which is how I took the screen shot).

So next step is some testing and then going back to the build system and fixing a few things "correctly".


Top
 Profile  
 
PostPosted: Sun Apr 19, 2009 7:10 pm 
Offline

Joined: Sun Apr 05, 2009 11:56 am
Posts: 8
Location: Chicago, IL
Very impressive :)
Didn't expect that it really 'worked'!
Just out of curiosity: How high, or better low, is the framerate?


Top
 Profile  
 
PostPosted: Mon Apr 20, 2009 4:44 pm 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
Running in QVGA mode (/minny) anywhere from >15fps (focused on probe with no other ships in sight) to <5spf (Seconds Per Frame) (fight scene begining of level 2).

The good news is that I played through level 1 OK and have managed to survive the 1st attack in level 2 (after you send out the probe), but I really don't think it's playable enough to test any further (and in minny mode you can't see the full build window as it's to big so I can't build any scouts!).

I think I should do a cleanup on what I have and check it in. Then I'll look into nanoGL so I can use the openGL ES drivers for the SGX.

F.Y.I. running glxgears shows 45fps so I think/hope the slow fps is mainly down to the 3D graphics.


Top
 Profile  
 
PostPosted: Sat Apr 25, 2009 9:28 am 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
FYI CPU agnostic getFcuntionCall has been checked in. Under *nix systems add --enable-generic-etg to test, for other build systems just add GENERIC_ETGCALLFUNCTION to your defines. Like I said before if any one with a PPC is willing to test this it I would appreciate it as it would check it uses the right regs (int or float).

Next job, clean up ARM fixes and check them in.


Top
 Profile  
 
PostPosted: Sat Apr 25, 2009 11:00 am 
Offline

Joined: Sun Apr 05, 2009 11:56 am
Posts: 8
Location: Chicago, IL
I will test it on MacOSX and see if I encounter any unforeseen consequences ;)


Top
 Profile  
 
PostPosted: Sat Apr 25, 2009 1:02 pm 
Offline

Joined: Sun Apr 05, 2009 11:56 am
Posts: 8
Location: Chicago, IL
I did a short test run on MacOS no problems so far but I only played for a few minutes. My old Macbook is horribly slow.

I needed to change an include from wrapped_functions.h to functions.h because you do some trickery in the make file and I didn't want to change the xcode building instructions.


Top
 Profile  
 
PostPosted: Sat Apr 25, 2009 2:22 pm 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
I'd be surprised if including functions.h directly worked as it would end up redefining some rather vital macros that ETG.h uses, that was the reason for the Makefile.am magic, so functions.h got pre-processed into wrapped_functions.h before ETG.c referenced it.

I found a good test was to scuttle the ships at the begining as that spawns lots of effects that call through etgFunctionCall.

I've got my build working for ARM and cleaned up, just fixing an issue when not cross compiling now and hopefully I can check it in today or tomorrow.


Top
 Profile  
 
PostPosted: Sun Apr 26, 2009 3:58 pm 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
ARM build fixes checked in. Tested build for x86 and ARM. Fixed build problem when not building with generic etgFunctionCall.

nanoGL investigation next (after sleep ;)).


Top
 Profile  
 
PostPosted: Tue Apr 28, 2009 4:49 pm 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
So after spending over 2 hours trying to convince OpenEmbedded to build SDL with debug, during which I found that as I'd messed up my mesa build and SDL was built without openGL support, I can finally debug what is happening.

Looks like I need to implement GLX functionality in nanoGL (miniGLX stype (http://en.wikipedia.org/wiki/MiniGLX)). I "bypassed" this (i.e. stepped over the code) to see what the next issue would be and it seems that nanoGL doesn't provide all the gl functions homeworld needs so I need to put some debug to see what's missing.

Time to crash out!


Top
 Profile  
 
PostPosted: Mon May 04, 2009 5:44 pm 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
Baby steps. Got my glX->EGL to compile and got it to start looking up function address, the problem is that glXGetProcAddressARB can and is used by homeworld to look up _every_ GL function address, where as the EGL equivalent only looks up address for the extensions. I hack something together that checks a function pointer table in nanoGL, but that only has the functions in the GLES library, I also need to ones in nanoWrap, that emulate missing OpenGL functions under GLES.

So next job is to rewrite glXGetProcAddressARB so it checks both libs (nanoGL & GLES) and see what's missing after that, but I do know it uses glBitmap and some pixel routines that aren't supported in nanoGL :/. Mind you there is another EGL->GL wrapper that might be more complete (http://forum.openhandhelds.org/viewtopic.php?f=14&t=884).

As midnight approaches, it's time to slip away, before they come!


Top
 Profile  
 
PostPosted: Thu May 07, 2009 5:27 pm 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
Unfortunately Homeworld uses about 35 functions that nanoGL doesn't implement, mostly pixel and line based. While I'm sure some could be easily worked around and some more functions implemented I think nanoGL isn't up to the job as far as Homeworld is concerned. I had a quick look at the other GL->GLES at mentioned in the previous post but that also is missing a vital functions.

Not being discouraged I've dug out something I found awhile ago which uses Mesa and implements the backend rendering using GLES (it also does the wrapping of GLX->EGL). It's an older version of Mesa then the I used for the software render, and I've hit some run time problems, but I hope I can fix these.

Not much will happen over the next week as I'm on hols :D so this will most likely be my last post before I'm back.


Top
 Profile  
 
PostPosted: Sun May 24, 2009 4:58 pm 
Offline

Joined: Sat Mar 29, 2008 11:06 am
Posts: 61
After reading the code rather then just hoping I see that the Mesa GLES project (glesport) also stubs out the pixel and bitmap operations and so doesn't seem to offer more then nanoGL does. So I've gone back to nanoGL. I ported the GLX->EGL wrapper from glesport as it was much more complete them what I had done and managed to get glxinfo to run.

Can't get glxgears to run as it requires functionality not yet implemented in the wrapper. I did try getting homeworld to run after implementing stubs for the missing functions but it looks like something is not quite right in the EGL initialisation, might be homeworld does it in a slightly different way to glxinfo so I need to dig down and see what the issue is.


Top
 Profile  
 
PostPosted: Tue Jul 24, 2012 7:53 am 
Offline

Joined: Mon Jul 23, 2012 7:06 pm
Posts: 1
What ever happened to this?


Top
 Profile  
 
PostPosted: Thu May 22, 2014 8:22 pm 
Offline

Joined: Wed Feb 15, 2006 1:26 am
Posts: 2
It got released in 2011:

http://web.archive.org/web/201108300311 ... world-sdl/


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 35 posts ] 

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group