Search results

It doesn't as long it wouldn't be much worse than in the PSP. But if it will be so weak (barely running Q3 in a very crippled conditions) then better GP deosn't position the XGP as "3D handheld" unless they want to generete some laughs. Are there any fillrate claims for the XGP? I couldn't find...

Imho 20fps for Q3 in 320x240 and with crippled settings isn't good. It's very poor and hardy at level of GF1. I could on weaker Voodoo4 play Q3 in 800x600 rather easily. If it will be really so 3D perromance wise for XGP it's not standing any chance against PSP. It might have problems even with...

It's handling more than just a diagonal issue in GP2x "MKI". It can reduce accidental registering of directions what are hard to no do given unrestrected movement of stock's stick bar. Try joytest up and move stick to UP then try move to LEFT or RIGHT from that UP position. Chances are you will...

You aren't alone - count me in! :) I'm using only Vim, a toolchain and Python for some quick utlities. Well... I was trying once to compile Quake1 but I failed. It can be done for sure but as I had something different to do... I don't have an idea about compiling squidgesnes in Linux thought...

And we can say the same in a reverse - it doesn't mean it's not legal. Well... laws do change all the time. What wasn't accepted 30 years ago is now. What is accepted now might not be after 30 years. How laws are changing it's a very complicated matter as well. How effectively laws can be...

Hi, The link: http://www.gp2x.de/cgi-bin/cfiles.cgi?0,0,0,0,19,1645 It's a realization in C of one of my ideas about improving handling the stock stick in software. Basically one function (a wrapper for GPIO input) and it could be easily added to any app/game. It has some small surprises as...

Thanks! Now I can work and talk again. :) I can provide a custom "firmware" if someone would have special needs. QD keypads (including the actual dpad) are very easy to buy on ebay. QD has springs and contact rubbers already built in. It's one (including availability) of its bigger pluses.

No it's still a valid aproach to music. Even better filters and effects could be add to usual sample playback. The 940T can handle it power wise. Depends on needed bandwith - if 1st core is already spending most of it then utilising 2nd core might results in reduced perfomance. The same as...

Yes. Even better if 2nd CPU would run something synth like. So no samples, no extra accesses to memory just final output to the codec. And such synth could fit into CPU cache and with 200mips possibilities are vast. At the profesional level I should add.

Oh please... do you think we cann't imagine why? :lol: And as I see it he succeeded. Are you Yuk Yuk or Garble? :) http://www.politicsforum.org/images/flame_warriors/index.php (an excellent link what was posted in latest flame thread) This is for real or it's just some kind of a weird...

Eeee... It will be matter of publishers policies nothing more. A game will get worse graphics on the Wii, such "asymmetrical" ports aren't nothing new.

Imho it's not worth. The build in plastic cover of LCD in GP2x is very resistant to a damage. I was experimenting with my GP2x much and to my surprise I didn't scratched it at all. But I wasn't putting my GP2x in pockets for an example. If you are planning to do so then perhaps this screen...

It can be done in two ways: - removing front LCD protector (will need hairdryer and some thin knife like object) - diassembling whole unit (not that hard but be carefull as LCD has some glue to front panel) At least they could make it more similar to DaveC's one. What they are now they aren't...

I guess there will be four options: - normal interpretor (for best compatibility) - dynrec with checks (for a compromise between perfomance and compatibility) - dynrec without checks (for the best perfomance) - dynrec with hand made patches to allow some nasty games to be run anyway under dynrec...

They are the same in one sense but selfmodifying code is doing its "thing" (selfmodifying itself) rather on a regular basis (even milions times per second) where reloading code from CD is done rather at bigger time intervals. Yes - PSX has a hardware 3D accelerator. It's not exactly advanced...

I have a plan but still some formal dilemmas to overcome. Sorry but I'm hardly conscious now as I should go to sleep some 5 hours ago... (coding can be damn addictive especially if there are results) I will answer questions and I'm willing to cooperate. But now I...

To tell the truth the openning /dev/fb0 device and using even "unsigned short int *" (drastically bad from efficiency standpoint as assembler ldm/stm will vaporize such code) and going after every pixel in usual x,y loop will be fast enough for many homebrew games. For fullscreen scrolling and...

Imho everyone should do in a way of a best proficiency. I'm very impressed with SDL as it's now with hardware acceleration. I like SDL and I'm using it on my PC for some of my utilities (written in Python) and done two or three proof of concept apps for GP2x. And it's perfectly valid option on...

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.

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...