My Mac: 1.8GHz single cpu G5, 1GB RAM, nVidia GeForce FX 5200
my stats:
4
22
100
after first level jumps to:
10
30
100
it stays at this even after restarting at level one via menu screen
high score page doesn't load for me.
matt
The Mac OS X Gridrunner++ Beta Test Thread **V 0.921**
-
matt
- Sheepie Whore
- Posts: 14826
- Joined: Mon Apr 22, 2002 4:07 pm 0
- XBL Gamertag: gingerbeardman
- PSN: wirehang
- Location: here && there
- Contact:
yes they are, charlie. to buy a mac for this one demo would be a bit OTT though!
My Mac: 1.8GHz single cpu G5, 1GB RAM, nVidia GeForce FX 5200
my stats:
4
22
100
after first level jumps to:
10
30
100
it stays at this even after restarting at level one via menu screen
high score page doesn't load for me.
matt
My Mac: 1.8GHz single cpu G5, 1GB RAM, nVidia GeForce FX 5200
my stats:
4
22
100
after first level jumps to:
10
30
100
it stays at this even after restarting at level one via menu screen
high score page doesn't load for me.
matt
Got a new version that's mosly had under the hood work done on it.
In fact I've made it slower.... on G5's for the benefit of G4. I haven't seen a G5 system that can't cope with GR++ really comfortably so I've changed the compiler to generate code that schedules well for a G4. It's made a big difference on my PB.
I also did a bit of profiling and found that glClear seemed to be taking a lot of time even though I didn't need to call it every frame as I'm doing no z buffer writes and the screen is completely rewritten every game frame. Taking that out gave a bit of a speed boost on older cards.
The general slowdown of the last version should also be resolved now. I have a thread that does the network io to send scores back to the mothership which I've now got working properly so it goes to sleep when there's nothing to do rather than stealing cycles from the main thread and slowing the game down.
I think I've now got to the point of diminishing returns on optimisation, the majority of the time is now stuck in OpenGL.
It would be really good if you can all play and test the speed of this version
If there is any more optimisation work to do I'd like to know now and get it out of the way. Cheers in advance
I've also done the initial code for handling software registration and the next job is to get the demo and final version into one app that's unlocked by a registration code
On the website side I'm using xmlrpc_server_* API that comes with PHP 5.0 which I don't have on my server that runs debian woody. I think that there's a donwloadable version of this api that I can use with PHP 4.0. I'll have a look at that after the reg stuff is done. It'll be cool to have everyone seeing everybody elses high scores
phew!
Getting there
Edit: 0.92 was fuxxorated by a misbuild so you need 0.921 which is linked below
http://llama.gazaxian.com//Gridrunner/g ... 00.921.dmg
In fact I've made it slower.... on G5's for the benefit of G4. I haven't seen a G5 system that can't cope with GR++ really comfortably so I've changed the compiler to generate code that schedules well for a G4. It's made a big difference on my PB.
I also did a bit of profiling and found that glClear seemed to be taking a lot of time even though I didn't need to call it every frame as I'm doing no z buffer writes and the screen is completely rewritten every game frame. Taking that out gave a bit of a speed boost on older cards.
The general slowdown of the last version should also be resolved now. I have a thread that does the network io to send scores back to the mothership which I've now got working properly so it goes to sleep when there's nothing to do rather than stealing cycles from the main thread and slowing the game down.
I think I've now got to the point of diminishing returns on optimisation, the majority of the time is now stuck in OpenGL.
It would be really good if you can all play and test the speed of this version
If there is any more optimisation work to do I'd like to know now and get it out of the way. Cheers in advance
I've also done the initial code for handling software registration and the next job is to get the demo and final version into one app that's unlocked by a registration code
On the website side I'm using xmlrpc_server_* API that comes with PHP 5.0 which I don't have on my server that runs debian woody. I think that there's a donwloadable version of this api that I can use with PHP 4.0. I'll have a look at that after the reg stuff is done. It'll be cool to have everyone seeing everybody elses high scores
phew!
Getting there
Edit: 0.92 was fuxxorated by a misbuild so you need 0.921 which is linked below
http://llama.gazaxian.com//Gridrunner/g ... 00.921.dmg
Last edited by gravy on Thu Nov 18, 2004 3:25 am 0, edited 1 time in total.
I've got the window shrink and also turning the mouse off in full screen modes on my shrinking todo listromanista wrote:well i'll be doing a review for the dutch/belgian mac games website macgames.be when it is ready (free review copy ? ), to get it a bit more well known over here...
gravy are you doing it all by yourself, or does yak himself does a lot as well?
oh and can't you make window enclose the game instead of the black areas left and right?
rick
It's just me working on it part time now and it should be complete next week
This might be me being a bit fick, but after watching Stuffit Expander take a while to decompress the latest build, I had a wander around the package and noticed that some of the sound files are huuuuge.... e.g. fire.wav is 1.5mb, szap.wav is 460kb...
Is this not a bad thing?
Just wondered is all...
For info, on my 700mhz eMac 384MB, AoF started at about 30/120/120 and gradually slowed down through the first two levels, peaking at about 80/220/230 ish in full screen 1280x960 true colour....
Not sure if that's any help...
Simon
Is this not a bad thing?
Just wondered is all...
For info, on my 700mhz eMac 384MB, AoF started at about 30/120/120 and gradually slowed down through the first two levels, peaking at about 80/220/230 ish in full screen 1280x960 true colour....
Not sure if that's any help...
Simon
"Who put the 'ram' in the 'ram-a-lam-a-ding-dong'?"
-
savethelasthumanfamily
- Baa!
- Posts: 74
- Joined: Fri Aug 23, 2002 6:52 pm 0
- Location: WI: USA
- Contact:
No. Why? Games come on multiple DVDs now, so a MB more or less doesn't really matter.goldfish wrote:This might be me being a bit fick, but after watching Stuffit Expander take a while to decompress the latest build, I had a wander around the package and noticed that some of the sound files are huuuuge.... e.g. fire.wav is 1.5mb, szap.wav is 460kb...
Is this not a bad thing?
-
matt
- Sheepie Whore
- Posts: 14826
- Joined: Mon Apr 22, 2002 4:07 pm 0
- XBL Gamertag: gingerbeardman
- PSN: wirehang
- Location: here && there
- Contact:
That is a completely backward way of thinking. And the reason you need 1GB of memory and a 160GB hard drive to do anything these days.skab wrote:No. Why? Games come on multiple DVDs now, so a MB more or less doesn't really matter.goldfish wrote:This might be me being a bit fick, but after watching Stuffit Expander take a while to decompress the latest build, I had a wander around the package and noticed that some of the sound files are huuuuge.... e.g. fire.wav is 1.5mb, szap.wav is 460kb...
Is this not a bad thing?
I remember the days when everything truly great fitted into 512KB RAM.
matt
Hey, hey, 16k!matt wrote:That is a completely backward way of thinking. And the reason you need 1GB of memory and a 160GB hard drive to do anything these days.
I remember the days when everything truly great fitted into 512KB RAM.
It doesn't really matter! Should the samples be downgraded to sound like crap just to save 10s of download time? Or should they use MP3 clips to slow down gameplay?
fire.wav is a bit evil 
When I first got the game going the sound was clicking and both fmod and OpenAL sound libraries were stalling, making the game go really slow.
I pinned it down to a problen to fire.wav, a 56k mono 22khz sample. To solve it I used audio hijack pro to capture 10 seconds of stereo 16 bit 44.1khz sample from mame of the firing sound in Defender that now takes 1.5mb
I'll change it eventually but I really like the rumble noise that carries on at the end of the level that comes from the fire sound playing all the way through
Worst has been the inclusion of Crypto++ that put nearly 1mb on the final compressed distribution. All I need is an ECSD signature test against a public key so if I can be arsed I may have a look round for a much smaller version.
There's also a load of .svn directories in the final bundle that needs stripping out.
With all this the crap in the compressed app now comes to about 4.7mb. I just did a manual strip and put the old fire wav in and it brings things down to 4mb.
Oh well, the aim is to keep it under 5mb which is apparently the golden size for shareware downloads and I can't see the game data getting any bigger than it currently is so it looks like I'm in target.
BTW I know what you mean about bloatware, some of the first games I wrote were on the NES where I only had 2k of RAM
When I first got the game going the sound was clicking and both fmod and OpenAL sound libraries were stalling, making the game go really slow.
I pinned it down to a problen to fire.wav, a 56k mono 22khz sample. To solve it I used audio hijack pro to capture 10 seconds of stereo 16 bit 44.1khz sample from mame of the firing sound in Defender that now takes 1.5mb
I'll change it eventually but I really like the rumble noise that carries on at the end of the level that comes from the fire sound playing all the way through
Worst has been the inclusion of Crypto++ that put nearly 1mb on the final compressed distribution. All I need is an ECSD signature test against a public key so if I can be arsed I may have a look round for a much smaller version.
There's also a load of .svn directories in the final bundle that needs stripping out.
With all this the crap in the compressed app now comes to about 4.7mb. I just did a manual strip and put the old fire wav in and it brings things down to 4mb.
Oh well, the aim is to keep it under 5mb which is apparently the golden size for shareware downloads and I can't see the game data getting any bigger than it currently is so it looks like I'm in target.
BTW I know what you mean about bloatware, some of the first games I wrote were on the NES where I only had 2k of RAM
I was thinking from two perspectives... if you're looking to optimise an application for speed, then I can't honestly imagine that shifting 1.5MB of code around is going to help. That said, I know precisely fuck all about programming, so am probably wrong.skab wrote:No. Why? Games come on multiple DVDs now, so a MB more or less doesn't really matter.goldfish wrote:This might be me being a bit fick, but after watching Stuffit Expander take a while to decompress the latest build, I had a wander around the package and noticed that some of the sound files are huuuuge.... e.g. fire.wav is 1.5mb, szap.wav is 460kb...
Is this not a bad thing?
Also from a download perspective. Maybe it's because I work on a large website and always look to optimise code (removing unnecessary 'spaces' and carriage returns here and there), removing a few kb on pages that can be downloaded millions of times is a major bandwidth saving. Replacing double-spaces with single spaces on our website cut out MBs-worth of unnecessary bandwidth.
I guess if GR++ OSX gets downloaded 1000 or so times then it's only a gig or so of bandwidth but....
Anyway, I tend to concur with matt that if you can reduce it, you should, but don't want to sound negative about gravy's work, which is pretty top notch IMO.
Cheers,
Simon
"Who put the 'ram' in the 'ram-a-lam-a-ding-dong'?"
-
limb_clock
- Baaaaaaa!
- Posts: 8186
- Joined: Fri Mar 28, 2003 9:46 am 0
- XBL Gamertag: LimbClock
- Location: Winland a.k.a. Finland