Gpquake 0.21


Not sure how many of you remember Gpvgb the old GB emu. Those of you who do might also remember that it was clocked to 99MHz and worked on about half of the units out there. I suspect you'll find the fact is that trying to set a unit to 99MHz will just introduce incompatibilities in at least half of the things for some reason. So 133MHz should fix that. I hope :)
 
Maybe you should just have a boot menu like the Doom port to select a clock speed? ;)

By the way, if you are too busy porting Quake then I could always code a frontend for you. Let me know what you think...

PS. This is one active thread :lol:
 
just tested both versions @ 166mzh with full version pak files.

0.20 (without gamma) works fine
0.21 (with gamma) crashes after loading the entrance level

Saveing/Loading doesn't work on 0.20 (Could not open)
I think it has something to do with using "/" or "\" in the filename because 0.20 tries to open
GP:\GPMM\QUAKE\ID1/S0.SAV

But it could be something completely different as I have not looked at the sources.
 
Incidentally, the bug may well drop back to the clockspeed as has been suggested, simply because GeePee doesn't take account of it - it runs everything at 40MHz (or as though it were at 40MHz) which is why its so slow. But it could be why it isn't affected by the bug that's killing it on real GP32s...
 
or due to some wrong compiler options (eg: alignment like suggested before)

however djwillis is adding his patches to the source right now and i know where my gp32 cable is.

but it'll take 1-? days until i got it back :(
 
Adjusting the gamma before starting a new game works pretty fine.
If I try to adjust it while running a game it crashes.

So I don't have to report any new bugs ;)
 
works fine on a 64 meg card and gamma works only if you put it on full (no crash or lockup) i,m very happy but yes it does seem slower less fps
 
I've not tested this particular compile myself yet (but going to in a second). I sent a 166mhz test of the gamma code to a couple of people and they reported exactly the same results as me - works fine if you set the brightness before begining a game, but crashes if you change if during (it's to do with a memory problem in the screen rendering code). I've no idea why other people are experiencing loads of crashes - it's possibly a compiler problem as it works fine when I compile it. Also, I don't know what that is about a 99mhz clock speed - my uploaded code uses 133 as I always test slow to save batteries but there should be no clockspeed slower than that in the code.
 
but i used your code and in initval_port.h the default clockspeed is set to 99mhz as far as i can see.

dunno if djwillis has spoken to yuo yet - he told me that he currently checks if he can put his clockspeed selector in the menu and his gamma correction code.
 
no_skill posted on Jul 20 2004 at 07:43 PM said:
but i used your code and in initval_port.h the default clockspeed is set to 99mhz as far as i can see.

dunno if djwillis has spoken to yuo yet - he told me that he currently checks if he can put his clockspeed selector in the menu and his gamma correction code.
Click to expand...
Yep, this version doesn't work for me either, but this exact same code when compiled on my machine worked fine :blink:. Don't have time to sort it right now, but I'll take a look later on tonight. Just for reference my version of gcc is 3.4.0 (am I correct in thinking you use 3.4.1?).

ignore initval_port.h - that just sets up some default values for any project. The actual clockspeeds can be found in sys_gp32.c - 133 is enabled and just comment it out and set another from the list to change it.

Not spoken to djwillis yet today. Just spent 3 hours traveling to a meeting that was cancelled, 4 hours waiting around (with no net access other than on my mobile :() for someone else to have a few meetings, then 3 hours traveling home again :(. I've had enough so now I'm off to the pub to moan to a few more people :).
 
Last edited by a moderator:
what a bad day!
have fun in the pub!

i'm going to work on my compiler problems tomorrow.
and i'll clean up the unnecessary but confusing parts of the code (like those files that won't be used).
 
Yo,

I can vouch for the alignment problems. I was trying to clean up the source a little, and some little thing could instantly kill it. I was getting pissed trying to figure it out when I figured it was some alignment faults. I added some code to turn off alignment exceptions, and now it's not having problems anymore. Well, not THAT problem, anyways.

Now it crashes when I start a game, but before it would crash before anything happened.
 
which compiler / settings do you use?

i wouldn't spent too much time on cleaning the code as huge parts will be replaced when merging with pocketquake 0062.

and woogal compiled the source on his pc and reported it worked just fine on his gp32.
 
I'm using GCC 3.4.0 from DevkitARM.

I got it to compile and run, but when I started changing stuff, that's when it stopped working. Really stupid things were killing it though, like commenting out an unused variable would cause an alignment fault. Now that I've messed with it a little more though, now it won't go in-game :(

Anyways, I'm sure it'll all get figured out.
 
i just found out that gpquake is already based on the latest pocketquake source...

however: your problems might be due to wrong compiler settings.

i had similar problems with c++ on mrmikos sdk (eg: having global variables crashes, having them local works fine).

we should ask woogal/djwillis for their makefiles.
 
You must log in or register to reply here.

Similar threads

SvOlli
Svorbis Version 0.9c Has Been Released
Replies
16
Views
2K
Protoss
P
Farox
Sdlbasic Runtime
Replies
2
Views
4K
Farox
Farox
sbock
Mame4all 2.2 Released
2 3 4
Replies
62
Views
10K
NEIL L
NEIL L
ptitSeb
  • Sticky
Beta ptitSeb's Beta Lair
29 30 31
Replies
614
Views
171K
gunrock
gunrock
Farox
Sdlbasic Runtime
Replies
0
Views
5K
Farox
Farox
Back
Top