More Stuff Using The Second Core ?

Would you like to see more stuff using the second core ?


  • Total voters
    18

Magic Sam

Forever Homebrew
Joined
Aug 10, 2007
Messages
2,542
Age
41
Location
Yuzu onsen
Hi,

Some days ago Senor Quack released rRootage for the gp2x :)

I think this miracle was only possible because he used the second core, the "famous" arm940t !

What kind of other cool stuff could be possible on gp2x, if the second core is used ?

For example, would a game like chromium b.s.u run on the gp2x ?

Bye, Magic Sam

p.s: what about a competition for which using the second core would be mandatory ?

p.s 2: what about gathering resources to make development on the arm940t easier ?
 
The second core is quite limited in its use. As you can tell by the posting for that game on the archives, it's being used to its maximum, on a slightly overclocked CPU, and still a ton of stuff had to be cut. It's also quite tricky to use and can introduce bugs (rRootage seems to have an issue if it's run twice without resetting the GP2X, for instance - that may or may not be because the second CPU isn't being reset properly). Additionally the stuff that can be easily ported is quite slim - the OpenGL interfaces are quite sparsely implemented and even if it does work, there are massive float / fixed-point speed issues. Most games that use OpenGL use floats, which are a worst-case scenario for the 940 as a GPU.

It is, after all, still a software renderer, running on a 200MHz-ish chip. If it's doing that using float-conversions, syncing with the screen / RAM / first CPU, etc. that's quite a task for even tiny little resolutions, as anyone who's ever used software renderers for anything will know. And it's very dependent on the design of the game in the first place, i.e. you can't just throw everything "complex" to the GPU like you would on a PC, and you can't just brute-force stuff on the CPU either. You are looking at designing specifically for it, from the ground up, or looking for perfect matches in existing software and putting a lot of work in.

I have no doubt that the 940 can help, but we're talking an awful lot of work to get games that would "almost" work anyway up to speed, not suddenly opening new vistas of possibilities. If something has an OpenGL requirement, gpu940 can help eliminate the requirement - but you're almost looking at the same work as just removing that requirement and doing it the hard way in the first place. The development for the 940 can't be made that much easier than if you use gpu940 - it's basically a mini-OpenGL library. Still, the extraneous work that has to be done on each project is the killer factor to a developer's time, not the library you use.

I looked into using gpu940 on my new game "Adsorb", because it would let me use some fancy effects to pretty the thing up a bit, but I decided it was just far too much effort. The 940 can help, but you get a lot more from just realistic expectations and if you're writing a game from scratch and it "needs" the 940, you're probably aiming it at the wrong console anyway.

And I think that most people would be unwilling to invest such effort as this into an "obsolete" console (not that I ever believe in any such things, I still play SNES and Spectrum games). Kudos to Senor Quack, though - yet another marvellous achievement. But that's a HELL of a lot of work for someone to do. Just be grateful that *anyone* is still looking at games for the GP2X / 940 etc. at all.

That said, the game you linked (or something very, very similar-looking) would probably be perfectly possible without OpenGL at all, judging by the graphics I can see of it. It looks like it was just an OpenGL learning toy for the author.
 
Thanks for the kind words, Ledow :)

I was pretty surprised to see how high the frame rate was for rRootage, even after taking everything out. I wasn't expecting hundreds of alpha-blended polygons rendered one atop the other would be kind to the GP2X but it is fine! rRootage uses floats just about everywhere, including many divides, so it is pretty amazing it runs as well as it does.


I was thinking the other day, that another nice use for gpu940 might be GLFrontier. The current GP2X version is a bit slow.
 
I remember somebody was doing work on some arm940 library that was supposed to make it's use easier. Don't remember how that ended, should be somewhere on these forums.
 
I really don't think the gp2x has ever had it's abilities really exploited. Look at some of the stuff that the Gameboy advance has done and the gp2x can emulate it, just imagine what it could with software written for it. Unfortunately, most of the software we get are ports and aren't really optimized for it. I look at the snes emulator (for example) and then look at picodrive! I really think if a snes emulator was written from the ground up to run on the gp2x, it would work with no frame skip and full audio, I think the amiga can be done as well.. I really think we could get some awesome games (well, more of them, there certainly are some awesome gp2x games) from a technical standpoint.
 
christo930 said:
I really don't think the gp2x has ever had it's abilities really exploited.

Of course... but the effort involved in that is orders of magnitude greater than porting, or just recompiling, or even creating a program that runs on multi-platforms and hence "accidentally" runs on the GP2X too. And all that extra effort costs an awful lot in terms of time, money, and effort. Look at Payback versus the other games - if you know what you're targeting from the start, have the funds to do it, and really aim for a particularly good port, you can achieve wonderful things. Unfortunately, you're then into "one-man-army" or paid development team efforts, something you rarely see in small games projects except for a few minor exceptions. (Though there are a few one-man-army developers that pop up every now and again after man-years of effort to release something amazing)

Emulators are even trickier - you have to have good knowledge of BOTH sides of the coin (emulated system, and the system emulating it) to get the most out of things and that's not a common trait. The Amiga would be pushing it, however, purely because of the number/speed of chips that need to be emulated correctly to get even a basic Amiga model emulated (but obviously there are shortcuts, as with everything else) but you're looking at man-years of effort and people don't like to invest that into a "toy" project that they are doing outside work, or on a system that might go away in a year or two.

That's why most of the big consoles have an example project that they release to show the capabilities when they are first sold - it's usually developed in tandem with the hardware development teams, with access to pre-release hardware, written almost "from scratch" (may use libraries, etc. but would be optimised to get a lot out of the system - not the maximum, but enough to show-off) and it doesn't really matter how long it takes / much it costs because it's a learning / development tool that's started while the hardware isn't even finalised. You can think of Payback as that sort of game for GP2X. The Pandora is currently in that stage too... people are trying to create a "killer app" which uses the hardware to the max and it looks like that might be a 3D port or something like an N64 emulator.

But as with all videogames consoles - after that initial "demo", 90% of what comes out is clones, ports and simple games because of the sheer effort involved in building something just for a single model of hardware. Why would you want to "waste" a lot of development effort by optimising towards only one piece of hardware when you could just write generic code and have it run on iPhone, PSP, GBA, Wii, PC, etc. with just a recompile?

That said, there were and still are some *amazing* things coming out for the GP2X... I just look at some of the things which are released and think "How the hell did they manage that?".

And I hate using myself as an example of a "developer" - my skills are far below those of others on these boards, but I can program in several languages and get things working from zero code when I have the incentive - but I have about four ideas for games that I want to write by myself at some stage. Some of those game ideas have been stuck in a perpetual hiatus as I try to make a start on them from scratch (we're not talking anything revolutionary, just simple indie-style games - one of them was almost identical to the game Sheep, but they managed to write that game before I ever could get my version properly written).

Even with libraries to aid development, there's a ton of code that I have to write to get the gameplay ideas I want to work as I would like and that's the hard part. Most of that is boring, repetitive, confusing and irritating, but it has to be done. Even when you clone a existing game, some of the hard work is done for you, even if you can't see the code (e.g. my clone of Osmos was pretty much started because I looked at Osmos and thought "Oh, wow, the mechanics of that game must be really quite simple but it's great fun to play"). My point is - when you have code, no matter how little, already written for you (either actually in a file, or in a format you can decipher mentally) writing programs is quite easy. That doesn't mean that it's without enormous effort, but it's significantly easier than starting anything for yourself.

This is why companies license things like the Quake / Half-life engines even from their main competitors - the effort involved in re-inventing that stuff isn't worth it when you can just give money to your rival. Now imagine that you want to write a GP2X game after work and in your lunch hour - you can either "steal" the GPL Quake engine (which works everywhere, is already done and tested, can be easily understood and ported but will never be "optimal"), or you can try to rewrite one completely from scratch optimised for the GP2X's ARM... generic wins every time which is why there are so few 3D game engines out there that use anything other than ID-Software-based engines.

Be grateful for what you have... I wouldn't even like to guess the man-hours that have gone into half the software on the archives, and all of it unpaid. :)
 
Last edited by a moderator:
ledow said:
christo930 said:
I really don't think the gp2x has ever had it's abilities really exploited.

Be grateful for what you have... I wouldn't even like to guess the man-hours that have gone into half the software on the archives, and all of it unpaid. :)

I have done some basic and assembly language programming in the past and I know how tedious and time consuming programming is (well, at least a small taste) and I get that. I certainly am not unappreciative of the hard work people here have done. And not just the programmers! There are people who help run the site, people who are very helpful in the boards etc, etc, etc. Most of the people who write free software do so for the love of doing it or the learning experience and things like that. There are also the types that want to see how far they can push the hardware. None of this changes the fact that it's disappointing that we don't have full speed emulation for systems that probably are technically doable. It's not like I think we are owed it or anything, just disappointing. I think everyone, especially the developers, would love to see the gp2x really pushed to it's limits, look at the excitement caused by the release of Rrootage.

Chris
 
Last edited by a moderator:
Inspired by other's attempts to offload sound processing to the 940T, I always wanted to create a module for MAME4ALL to offload YM-2151 sound processing to it. I don't think I'm going to get around to it though.
 
offloading the sound proccesing to the second core would be a huge speed up for the snes emu, like 10-20%+, that could make games like BoF2 work almost fullspeed
i have very basic C++ skill, and learning on my own. but as far as i've gone (reverse engienering a psx file archiver, and makeing a program to extract,add files from it) i pretty much know the time needed to think and write , then finding out that something just doesn't do what it's supposed to, and spend even more time finding the bug and finding out how to fix it and If there isn't a way to fix it even more finding out a work arround.
 
Back
Top