GP2X Just Started Coding


Jarulf

Still Fresh
Joined
May 23, 2006
Messages
4
Age
38
Location
Skellefte
Website
Visit site
Hello.

I ordered my GP2X in the beginning of this week, and I will get it in two days, so to make the time pass I started coding some simple things in SDL.

One thing that impressed me was one big difference between SDL and languages i previously coded(C++, Java etc.), the way to handle graphics in SDL. Big thumbs up.

Anyways, the things I've coded so far might end up on SourceForge, if my project gets approved. It's not anything big right now, mostly just small simple things. I figured that maybe someone somwhere want's to see the things i code, maybe for learning or for a good laugh :)
 
Hi, hope you have fun coding with your gp2x when it comes. It's lived up to all my expectations and more. Its a great little toy. :)

Go read the demo coding tut, you may want to drop SDL and do it your self. ;)
 
I don't see why you'd recommend that. You can do amazing things with SDL at incredible speeds, with proper planning and execution... what is with the misconception anything that runs fast on the GP2X can't use Linux, SDL or C? :p
 
Epicenter posted on May 31 2006 at 12:36 AM said:
I don't see why you'd recommend that. You can do amazing things with SDL at incredible speeds, with proper planning and execution... what is with the misconception anything that runs fast on the GP2X can't use Linux, SDL or C? :p

Yer, after I typed that I thought it sounded a bit 'anti' SDL. Its prob better to use SDL if your a beginner, its just that coding it your self on the 940 is so much fun! :)
 
Last edited by a moderator:
Epicenter posted on May 31 2006 at 12:36 AM said:
I don't see why you'd recommend that. You can do amazing things with SDL at incredible speeds, with proper planning and execution... what is with the misconception anything that runs fast on the GP2X can't use Linux, SDL or C? :p

Why is it Epicenter, that everytime i read "SDL" on these forums, you‘re always there, praising it? In fact, to come to think of it, your always praising it, even if no-one has brought the topic up?

BTW i have nothing against SDL, just an observation
 
Last edited by a moderator:
For whatever reason you got the impression, I'm not its advertiser. But you'll find I stick to arguing beliefs of which other people choose to argue misconceptions about them .. like that the Linux implementation on the GP2X causes horrific slowdown in homebrew applications (absolute nonsense), that SDL is the slowest thing to walk the Earth (since so many slow, poorly-coded applications have been written for the GP2X using it), that the 2nd core in the GP2X is utterly worthless, things like that.

In this case, if you ever wrote an engine in ASM you'd know why I'd argue against a beginner trying it here.
 
For whatever reason you got the impression, I'm not its advertiser. But you'll find I stick to arguing beliefs of which other people choose to argue misconceptions about them .. like that the Linux implementation on the GP2X causes horrific slowdown in homebrew applications (absolute nonsense), that SDL is the slowest thing to walk the Earth (since so many slow, poorly-coded applications have been written for the GP2X using it), that the 2nd core in the GP2X is utterly worthless, things like that.

In this case, if you ever wrote an engine in ASM you'd know why I'd argue against a beginner trying it here.


Hey, everything you just said about linux, ASM, the second core and SDL I thought was true. Well from looking at the apps It would show that to be true anyway. Linux prevents reading the screen for raster interrupt pallete switching, the second CPU is only accessed to shut it off to save power, and GP32 equivilents of emus without linux run faster at lower clock rates like 166 MHz than the GP2X does overclocked. Plus Megadrive and NeoGeo emus using "c" cores were unplayably slow. I don't know maybe it is a misconception but everything is proving those "urban legends" of the GP2X world to be true..
 
Last edited by a moderator:
Well, to put things in perspective, the engine I'm using for Stargazer, WITHOUT using the blitter, achieves over 115 FPS performing far more graphical processing work than any other homebrew title using SDL I've seen-- this is with an OGG Vorbis audio file being played at the same time as the game runs. Will things be faster if written from the ground up in ASM or working with the hardware on a memory-address basis? Yes. Is SDL slow? By no means.

ASM-- I never said an emulator with a C core should be fast! They generally are not. C-based CPU Cores are notorious for being slow, and their only advantage is crossplatform compatibility with just a recompile. Of course, an ARM9 ASM 68000 core like Cyclone is lightyears beyond a C-based one, same goes for DrZ80 and others.

Linux-- not sure where this bit about the GP32 running emulators faster at lower clockrates THAT dramatic comes from. Now, you say the GP32 overclocked to 166 MHz outperforms 'the GP2x overclocked'-- the average overclocked speed people use on the GP2X is 266 MHz. I've not seen one emulator whose GP32 iteration ran faster given that skew of clockrate and the same CPU architecture, just because of the operating system sitting between the hardware and emulator. I saw .. I believe it was a PC-Engine emulator that ran faster on the GP32 at 166 MHz than the GP2x at 200 MHz. That sort of a difference is logical, a 100 MHz clock defecit on the same architecture and still yielding performance gains is quite unlikely unless the two programs are not on a level playing field-- e.g. the GP2X version uses a C CPU core and the GP32 version an ARM9 ASM core. That's not exactly a fair competition. The PCE scenario is the ONLY comparison of this nature I've seen drawn-- I recall watching the thread with interest. If you have more examples, I'd love to hear them. But I watch this forum with a hawk's eye for topics of interest and I've seen no others crop up.

As for NES emulation, we're now seeing a good NES emulator (GPFCE) run most NES games at 100% speed at the stock 200 MHz with a C 6502 core-- when an ASM core is implemented, I'd expect a full 60 (or 50 in European games) FPS at *100* MHz ARM920T clock or perhaps lower, as this is the most stressful bit of the emulation.

GB Emulation? Again, matches the GP32's offerings amazingly well. SMS/Game Gear? You can run games at full speed with 920T clockrates well below 100 MHz. In fact they can run faster than full speed there. MegaDrive emulation? On par with how it ran on the GP32, but capable of far more due to the ARM9 achieving clockrates >200 MHz-- MD emulation with DrMDx really comes into its own at 230-250 MHz.

Do try running a MegaDrive or NeoGeo emulator with a C core on the GP2X and the GP32. It will be very, horribly slow on both. It'll be slow on some older PCs, too. I'm not talking ancient history, more the Pentium III/K6-2/3 based class of computers from not very long ago.

I don't get your argument about the 940T. You say it's only accessed to be turned off? Did you forget about its role in video playback? It's a fully-capable ARM9 processor at 200 MHz by default, it just lacks an MMU and has less cache than its big-brother 920T so is not as simple to utilize, e.g. in an SMP-style setup. It can be used to do many helpful things; one individual on this forum is writing a 3D engine that utilizes it for example, so does Vektar, and this early on, you can be quite certain they won't be the last applications to do so-- it just requires knowledge and finesse to operate the 940T effectively.

Linux's impact on software interaction with the hardware affects a quite small set of cases-- SNES emulation is not faulty due to Linux, it's faulty because of a NUMBER of issues, e.g. a problematic implementation of transparency emulation-- Note that SNES emulation was horrible faulty until just a FEW years ago-- a high-quality working SNES emulator update was a SLASHDOTTED EVENT! It's not logical to expect incredible, PC emulation-scene equivalent performance from the GP2X on the same task this early on, and dropping Linux out of the equation won't be an instant 'easy button' to trigger ideal SNES emulation on the platform by any means. There are some gains it could provide, but they are not as significant as they are blown up to be, won't independently provide stellar SNES emulation and will open several new cans of worms in terms of complexity for development and operation. It's also one of very few applications where working closer to the hardware is feasible and has a probably-favorable returns-to-investments ratio for the developer in terms of invested time and gained performance.

What will provide the most immediate gains in SNES performance emulation? An ASM core for the 65c816 CPU. That's right, it's a *C EMULATION CORE*, like you just said-- very very slow, near unplayably slow, when used in most applications. Lots of optimization, cleanup, and bug-fixes. Seeing as removing a battery meter just added a supposed 10 FPS to overall performance of the emulator, that says a good bit about how much work is left to be done on it-- and makes it clear it's nowhere near hitting a performance ceiling created by Linux.
 
I believe it was a PC-Engine emulator that ran faster on the GP32 at 166 MHz than the GP2x at 200 MHz. That sort of a difference is logical, a 100 MHz clock defecit on the same architecture and still yielding performance gains is quite unlikely unless the two programs are not on a level playing field-- e.g. the GP2X version uses a C CPU core and the GP32 version an ARM9 ASM core.

The PC engine emu was an early version of Vobbos. He said he used the EXACT same code base and ported it to the GP32.

Reesy also stated that his SMS emu ran at 66 MHz on the GP32 but needs 100 on the GP2X for the same basic code. He went on to curse linux too ;)

I don't get your argument about the 940T. You say it's only accessed to be turned off? Did you forget about its role in video playback? It's a fully-capable ARM9 processor at 200 MHz by default, it just lacks an MMU and has less cache than its big-brother 920T so is not as simple to utilize, e.g. in an SMP-style setup.

I didn't forget about video I just could care less about video. I am talking emus here. For emus it is turned off, useless. I also heard other coders say that using the second core would actually SLOW DOWN the emulator due to bus contention etc.

What will provide the most immediate gains in SNES performance emulation? An ASM core for the 65c816 CPU. That's right, it's a *C EMULATION CORE*, like you just said-- very very slow, near unplayably slow, when used in most applications. Lots of optimization, cleanup, and bug-fixes.

It was based on Yoyos code which uses an ASM cpu core,

Read here:

http://www.gp32x.de/board/index.php?showtopic=17552&hl=

Also from his credits section of the readme file:

"yoyofr/thunderz/laxer3a -> OpenSnes9XGP (lots of code taken from this, including asm cpu core, etc)"

So bad news about the speedup from a ASM cpu core as it already has it. Like I said the only thing still in "c" is the sound mixing.
 
Last edited by a moderator:
So, all you care about is emulation, then? It would certainly appear so. Shortsighted, but I can't change your opinion.

Again, you quoted to me 2 emulators that run at a speed equivalent of the GP32 running ~33 MHz slower-- just like I described being 'logical'. So, what about your remark that the GP2X 'overclocked' could not keep up with a 166 MHz GP32 which is BELOW the default 200 MHz spec of the GP2X's main CPU? Do you have evidence to support that? I do not believe such a case exists. If it does, I encourage you to prove it to me.

Port SquidgeSNES to the GP32 and find a means to overclock the machine to 266 MHz, and you will not see full-speed emulation. Period.
 
So, all you care about is emulation, then? It would certainly appear so. Shortsighted, but I can't change your opinion.


I guess if you call liking emulation and not watching movies (which seems to be the main use of the second core) on a little tiny screen "shortsighted" then yeah I guess. To me I would rather watch a movie on a bigger screen with better sound and not on some little cheap PMP , just me.
 
Last edited by a moderator:
I'm not going to argue mentality in purchasing the GP2X, different strokes for different folks. I'm just arguing the above points, which I'm yet to agree with you on..
 
For whatever reason you got the impression, I'm not its advertiser. But you'll find I stick to arguing beliefs of which other people choose to argue misconceptions about them .. like that the Linux implementation on the GP2X causes horrific slowdown in homebrew applications (absolute nonsense), that SDL is the slowest thing to walk the Earth (since so many slow, poorly-coded applications have been written for the GP2X using it), that the 2nd core in the GP2X is utterly worthless, things like that.

In this case, if you ever wrote an engine in ASM you'd know why I'd argue against a beginner trying it here.

Hey, everything you just said about linux, ASM, the second core and SDL I thought was true. Well from looking at the apps It would show that to be true anyway. Linux prevents reading the screen for raster interrupt

Why do you want a raster interrupt when the framebuffer can be redrawed numerous times using just a CPU?

Rasters were fun and all on the machines with slow CPUs like Amiga or ST. But on the GP2x even without resorting to blitter or videopostprocessor just the 920T can do much, much more.

pallete switching, the second CPU is only accessed to shut it off to save

Palletle cycling tricks were nifty in the old times. I remember them and they were especially fun on the VGA what for first time had the 256 positions for color lockup table.

But I prefer direct mapped RGB pixel (16bpp) and fast CPU for some reasons. And you can do CLUT tricks under Linux.

power, and GP32 equivilents of emus without linux run faster at lower clock rates like 166 MHz than the GP2X does overclocked. Plus Megadrive and NeoGeo emus using "c" cores were unplayably slow. I don't know maybe it is a misconception but everything is proving those "urban legends" of the GP2X world to be true..

Well.. old good DaveC. :D
 
Last edited by a moderator:
It took me an entire work-week to learn and implement (very basic) multithreading in C#.NET, which is like cheating compared to what my dad and some folks here do.

What I would love to see is links to technical dissertations on multithreading the GP2X, or code samples. I'm sure they are out there, I'm just ignorant about their locations, and it's not something easily Googled. GP2X tutorials I've read don't step on it, though I read at least one does.

To me, not using the 2nd CPU sounds horrible at face value: It either means that the GP2X is horribly made, or that coders have a horrible conception of how to use it. Given the complexity of multithreading in general, and the GP2X's track record for quality (less than perfect, but not horrible), it is difficult for the lay-person to pin-down the answer.

Edit: Replaced "this" with "multithreading the GP2X"
 
To me, not using the 2nd CPU sounds horrible at face value: It either means that the GP2X is horribly made, or that coders have a horrible conception of how to use it. Given the complexity of multithreading in general, and the GP2X's track record for quality (less than perfect, but not horrible), it is difficult for the lay-person to pin-down the answer.

Problem with multicore machines is the same as always - an algorithm must be divided between cores. It takes planning, thinking and brings other issues. It's possible a time could be better spend on improving existing single core code than engage in dual core. In the end results only count not how they were achieved.
(It's more complicated in GP2x because the 2nd CPU doesn't have a MMU. Threads can not be scheduled os wise on it.)

It's why Im not touching blitter in my 2D lib. It's simply unnecessary because I found a nifty algorithm for doing scrolling/sprites in a pure software. And as blitter is somewhat featureless (it can not do RGB color mixing when blitting) adding support for it wouldn't bring that much of boost for whole engine.

But for SDL blitter is great - an apropriate tool for the task.

The same goes for second core - it's imho senseless try to use it only because it is. If it fits the task then great. If not then perhaps there is more to gain by focusing on improving code for a single CPU?
(and in PC'dom we have the same dualcore issue - efficiency of using multicore system)
 
Last edited by a moderator:
I code in C++ and use SDL I have found nothing slow about it. That fact that the GP2X uses linux is a plus because it lets losts of things to be ported over rather quickly instead of from the ground up.
If you are a programmer and think SDL and C++ is slow then you are not much of a programmer/or just do not know how to optimize :blink:
 
GP2X_Future_Coder posted on Jul 5 2006 at 09:20 PM said:
I code in C++ and use SDL I have found nothing slow about it. That fact that the GP2X uses linux is a plus because it lets losts of things to be ported over rather quickly instead of from the ground up.
If you are a programmer and think SDL and C++ is slow then you are not much of a programmer/or just do not know how to optimize :blink:

It was to me? :)

If so I wasn't claiming that blitter accelerated SDL is slow or whatever. But it has its limitations, at least on GP2x there some things what are no go in SDL. Ihmo a tool should be apropriate for a task. For what I'm enduring it's not appropriate.
 
Last edited by a moderator:
I was just talking in general I wasn't singling you out at all Radek. I think one of the main problems with coding for the Gp2x is that GPH hasn't release proper docs/samples of the machines ablities. It takes people like us to find them on our own like Squidge Mmu Hack and paeryn hw sdl to get some of the true power behind the machine. If they would release an sdk that was able to tap into the features we could see what the gp2x can really do then there would be less problems with speed.

Thats just my opinion anyway :)
 
Back
Top