Viral18 said:And that is the origin of the GP32x forums WHATS YOUR ORDER NUMBER??!! Meme. Join us in a fortnight for the explanation on 2 months™...
FTFY
Last edited by a moderator:
Viral18 said:And that is the origin of the GP32x forums WHATS YOUR ORDER NUMBER??!! Meme. Join us in a fortnight for the explanation on 2 months™...
I'm sure, Apple Fanboys will tell us the opposite. :lol:EvilDragon said:There is no dream machine.
Very true. Each console has a huge Quality difference between the first games and the last ones. Maybe only in Graphics Quality (Super Mario and Mario 64 were early games BUT great games too) but I'm sure, if the Devs can manage to use the Hardware Features of the Pandora, things really get interesting. At the Moment we still have alot "Software only" stuff and without the new Kernel, better Drivers and Access to NEON/DSP 'n Stuff the Pandora will not get the attention that she deserves.EvilDragon said:Yes, it's the same hardware - but games significantly have been improved. The hardware was way better used.
Same for Amiga, C64, Genesis, etc. Just compare games like PacMan to Turrican. Same hardware, different time.
Early PSX games looked like crap. Final Fantasy VII? Great game, aweful 3D graphics, compared to FFVIII or FFIX.
fusion_power said:I'm sure, Apple Fanboys will tell us the opposite. :lol:
If by "dream machine" you mean "fairly good" then I guess MBPs qualify. Well, except for the low number of USB ports and the positively shitty screens of the unibody 13" MBP (hello, ghosting). The build quality's pretty good though and Apple has a very nice power connector. Oh, and my iPod touch was really worth its price (30 EUR through a promo offer).fusion_power said:I'm sure, Apple Fanboys will tell us the opposite. :lol:EvilDragon said:There is no dream machine.
I think allot of it is because the few heavy hitters like Notaz are all tied up doing OS stuff (No Picodrive updates etc). Exophase has Temper, the best PC-engine emu ever but has hit a snag with WiFi and won't release. Pickle? I am not sure maybe OS stuff. Skeezix never has much time. Maybe devs are just getting bored of porting to various gadgets? I don't know.Ian_J said:I'm tempted to stop visiting these forums, a lack of definite updates and any worthwhile progress is really getting me down.
Ian
I don't have a Pandora yet.Ian_J said:I'm tempted to stop visiting these forums, a lack of definite updates and any worthwhile progress is really getting me down.
Ian
With respect to gpSP, there are a few reasons: first, Exophase is not interested in working on it. That said, I believe the source is available (and I don't see why Exophase wouldn't give access to the code to someone who was willing and had the skills to port it). Second, it's really a very complex emulator (uses a dynamic recompiler), and probably hits the hardware directly to do some stuff.DaveC said:Then there are ports you just think would be easy to do and would be available like GPsP (that would actually run GBA fullspeed with no overclock or frameskip) and the GP2X/Wiz fast MAME version, but I haven't even heard anyone was doing it.
DaveC said:Exophase has Temper, the best PC-engine emu ever but has hit a snag with WiFi and won't release.
DaveC said:To me I have to say I am a bit dissapointed by the menus in the emus. No button configs, bad ROM selectors have you weaving your way through a cryptic linuxy directory tree everytime you load them, no overclock functions built in (loading that separate app everytime you want to change speeds is a PITA.) Then some menus REQUIRE you to pull out the stylus and use the touchscreen because the coder didn't feel like changing the interface to be useable with a d-pad etc.
Ok, last I heard wifi was holding it up.Exophase said:DaveC said:Exophase has Temper, the best PC-engine emu ever but has hit a snag with WiFi and won't release.
You've got the story all wrong. It's more like the wifi core is working fine, I just need a few more days to get the GUI in place and polish up a couple things and it'll be ready for release. Lately I've been busy with other things and this is the sort of stuff I'm not enthusiastic about doing, so it takes a little longer than usual. I'll also be out of town this Friday and weekend. But it's really close to being released, don't think that it's on some kind of indefinite hold.
And this is why I don't rush a port out, to get simple usability concerns like this taken care of.
I'm trying to get the QT front end for CaPrICe done, but I seem to have taken over porting Firefox and Comix. If you'd rather do them I'll get right back on that UI...DaveC said:...
To me I have to say I am a bit dissapointed by the menus in the emus. No button configs, bad ROM selectors have you weaving your way through a cryptic linuxy directory tree everytime you load them, no overclock functions built in (loading that separate app everytime you want to change speeds is a PITA.) Then some menus REQUIRE you to pull out the stylus and use the touchscreen because the coder didn't feel like changing the interface to be useable with a d-pad etc. With the port itself from the GP2X being fairly straight forward you would think time would be spent spiffing up menus and adding useability/intuitive options. To me that is my biggest dissapointment, many of the emus are simply a pain to use. It can take minutes by the time you load and set CPU speed app, then go through the tree to find your ROM etc(I swear not knowing linux in the beginning it took me 10 minutes once to load a ROM because I couldn't find the correct MMBLK1123, mnt,mm,menublk1/media/pandora/menu or whatever the hell it was and just had to keep guessing at things) . Look and feel and ease of use makes a big difference in a device. That is probably why Apple has such tight control over apps. I would hope over time these menus will get better and some kind of loose standard will be used like user selectable button configs, ROM path saving, clock settings etc. LOTS of work is needed in the interface department. If I could code I would contribute here and fix all of the menus where source was available.
That reminds me of other thing. Some of these interfaces rely heavily on linux, window managers and other external bloat. I think that menus should be self contained so that they will work no matter what you are using. It is conceivable that a version of minimenu for example could be released in the future that is fast booting without all of the linux bloat.hdonk said:I'm trying to get the QT front end for CaPrICe done, but I seem to have taken over porting Firefox and Comix. If you'd rather do them I'll get right back on that UI...DaveC said:...
To me I have to say I am a bit dissapointed by the menus in the emus. No button configs, bad ROM selectors have you weaving your way through a cryptic linuxy directory tree everytime you load them, no overclock functions built in (loading that separate app everytime you want to change speeds is a PITA.) Then some menus REQUIRE you to pull out the stylus and use the touchscreen because the coder didn't feel like changing the interface to be useable with a d-pad etc. With the port itself from the GP2X being fairly straight forward you would think time would be spent spiffing up menus and adding useability/intuitive options. To me that is my biggest dissapointment, many of the emus are simply a pain to use. It can take minutes by the time you load and set CPU speed app, then go through the tree to find your ROM etc(I swear not knowing linux in the beginning it took me 10 minutes once to load a ROM because I couldn't find the correct MMBLK1123, mnt,mm,menublk1/media/pandora/menu or whatever the hell it was and just had to keep guessing at things) . Look and feel and ease of use makes a big difference in a device. That is probably why Apple has such tight control over apps. I would hope over time these menus will get better and some kind of loose standard will be used like user selectable button configs, ROM path saving, clock settings etc. LOTS of work is needed in the interface department. If I could code I would contribute here and fix all of the menus where source was available.
As was mentioned in the mupen thread, for emulators that work with X11 I'm pretty sure you can make a script which sets the CPU speed and map it to a button. I'm sure if you ask for one, some one will make it pretty easy.no overclock functions built in (loading that separate app everytime you want to change speeds is a PITA.)
If you could code you might realise:To me I have to say I am a bit dissapointed by the menus in the emus. No button configs, bad ROM selectors have you weaving your way through a cryptic linuxy directory tree everytime you load them, no overclock functions built in (loading that separate app everytime you want to change speeds is a PITA.) Then some menus REQUIRE you to pull out the stylus and use the touchscreen because the coder didn't feel like changing the interface to be useable with a d-pad etc. With the port itself from the GP2X being fairly straight forward you would think time would be spent spiffing up menus and adding useability/intuitive options. To me that is my biggest dissapointment, many of the emus are simply a pain to use. It can take minutes by the time you load and set CPU speed app, then go through the tree to find your ROM etc(I swear not knowing linux in the beginning it took me 10 minutes once to load a ROM because I couldn't find the correct MMBLK1123, mnt,mm,menublk1/media/pandora/menu or whatever the hell it was and just had to keep guessing at things) . Look and feel and ease of use makes a big difference in a device. That is probably why Apple has such tight control over apps. I would hope over time these menus will get better and some kind of loose standard will be used like user selectable button configs, ROM path saving, clock settings etc. LOTS of work is needed in the interface department. If I could code I would contribute here and fix all of the menus where source was available.
I think this is a bad idea. The whole point of the "linux bloat" is to give a standard interface to the programs.That reminds me of other thing. Some of these interfaces rely heavily on linux, window managers and other external bloat. I think that menus should be self contained so that they will work no matter what you are using. It is conceivable that a version of minimenu for example could be released in the future that is fast booting without all of the linux bloat.