Wiz Software Ready At Launch?


Wolfspirit

Member
Joined
Mar 17, 2003
Messages
178
Age
44
Is there somebody already going to be compiling the software from the gp2x for the wiz before it's actually launched and if so is there a list already of emulators, games, etc.? If not, is it as simple as setting up make on the wiz and doing a make/install? Also, any word on the actual release dates yet for the Wiz? Thanks.
 
It really depends on what coders are going to port their stuff from the GP2x over to Wiz for launch or not. I have no official news whatsoever, but with this thing being toted around as capable of playing PSX games, I'd like to see at least a semi-optimized emulator at launch. :D
 
Wolfspirit said:
If not, is it as simple as setting up make on the wiz and doing a make/install?
Unfortunately, it isn't. The Gp32 and Gp2x had a demigod called Rlyeh that created a wonderful library after tons of work: minimal lib. Most emulators in the Gp2x use that library that is not compatible with the Wiz. I know that there is at least a developer working on a "Wiz minimal library", but most emulators will need some work to be ported from Gp2x to Wiz. Fortunately, this work is the same that porting to Pandora so many ports could be published on Pandora and Wiz at the same time.

Most homebrew games, in the other hand, use SDL. Porting SDL programs from Wiz to Gp2x is just a "make" step. There will be a Fenix interpreter at launch, so games in Fenix won't even need recompilation.
 
Last edited by a moderator:
Anything I goof around with on GP2X (freesci, RACE!, wolf3d (although I might leave that to pickles, he did a pretty good job with Wolf4SDL)) I'll try and get going soon after launch, but I don't have an early developer version of any of the new handhelds, I just have to place my preorders and wait like everyone else...
 
"Big Free Racing"(remake of "Big Red Racing" featuring track editor and new gamemodes)
"Terminal FuryBender"(guess what the hell it is :D )
 
Well, I assume that anything SDL will just compile straight over but it all depends on what versions they use etc. The GP2X had built-in libraries that were outdated quite quickly and so the advice was to just compile against a newer version statically (so the new library is actually *inside* the executable, rather than trying to load one from the GP2X seperately). The "official" GP2X development environment was old quickly and was ignored unless you were making kernel modules (because you had to use it then). So it depends on how good a job they do with putting out a development environment - i.e. timing, versions, compiler, included libraries etc.

If it was just a matter of recompiliing, then I'd have a shot at recompiling some of my things for it but I can see there being many potential problems if they just do a quick job. Silly things, like the button assignments changing (so that, say, button 1 is UP on the GP2X but DOWN on the Wiz etc.), sound frequencies breaking like they did with the F-200's, etc. They seem to be sticking to most things - if they'd changed the resolution, for example, you could create a lot of work for the smaller projects or the SDL libraries in order to cope. There's some things that can't be helped, like the video RAM, video decoder firmware, sound buffer etc. will probably change location so anything that's hard-coded those values will need more than a recompile - anything that uses the mmuhack module, for instance, will need an updated version or some primitive code removal to remove references to it.
 
ledow said:
If it was just a matter of recompiliing, then I'd have a shot at recompiling some of my things for it but I can see there being many potential problems if they just do a quick job. Silly things, like the button assignments changing (so that, say, button 1 is UP on the GP2X but DOWN on the Wiz etc.), sound frequencies breaking like they did with the F-200's, etc. They seem to be sticking to most things - if they'd changed the resolution, for example, you could create a lot of work for the smaller projects or the SDL libraries in order to cope. There's some things that can't be helped, like the video RAM, video decoder firmware, sound buffer etc. will probably change location so anything that's hard-coded those values will need more than a recompile - anything that uses the mmuhack module, for instance, will need an updated version of some primitive code removal to remove references to it.
The button assignments are the same. What are you on about with the mmuhack?
 
Last edited by a moderator:
Since when did people start calling the buttons by a number? I've always called the UP key "UP" rather than "Button 1", and if your using SDL or Minimal lib, then these are definitions in that library that can be changed if needed and will automatically apply to all code that uses them.

Orkie: I think it means references to mmu hack will have to be removed, along with the references to the upper memory used to store data. I don't think there's many of these types of programs however.
 
Back
Top