My Loyalty Under Fire.


Alex. posted on Oct 30 2006 at 10:03 PM said:
HydraLancer posted on Oct 30 2006 at 06:01 PM said:
With this I do agree in order to carry out our game in its large scale, that another machine with better hardware may be the best choice.
Give proper reasons as to why the GP2X hardware is not capable of handling decent native shoot-em-ups.

- Alex
Well its not that the GP2X isn’t capable of creating a shmup game, when it most defiantly can and is possible, it’s more that at the stage we are in the project the XGP may have more of the required horsepower to create a much more graphical version of this particular game and make it easier to develop without weaving through hardware certain hardware specs. Not saying a shmup can’t be made, its that was trying to make a game at a certain level of detail, something far greater than a 386 game for certain.

One very important aspect of the XGP is that with a 2D accelerator not so much has to be done on the processor so the game won’t be bogged down by so many tasks being handled by it. Another weakness includes the blitter which isn’t the most wonderful and offers the only a slight improvement unless really taken advantage of code wise, but by comparison to a 2d accelerator the blitter isn’t a match. I mean although the Nintendo DS does not have a processor as powerful as the Gp2x, its power is incomparable merely because of its Video acceleration.

The memory is ok and many of the other hardware specs are as well but I believe the game can be taken further to more of the level I have in mind rather than the level that may be accomplished by the GP2X. No offence to anyone but I just think better things may come from what’s ahead.

Like I said it’s a great system, but such as Zelda III was taken mid development to the Super Nintendo from the NES, I believe more can be accomplished with what’s around the corner.

-hydra
 
Last edited by a moderator:
If what you are looking for is sprite rotation and stuff, yeah I agree the GP2X should have hardware support. But still, there are fast algorithms for that sort of thing, and 200MHz is plenty to pack in a lot of graphic effects in software. Ah well, whatever :)
 
HydraLancer posted on Oct 31 2006 at 04:28 AM said:
Like I said it’s a great system, but such as Zelda III was taken mid development to the Super Nintendo from the NES, I believe more can be accomplished with what’s around the corner.

-hydra

So since the game is scrubbed for the GP2X shouldn't you change your sig? It is kind of misleading.

Why wouldn't you do the game for the PSP or DS? Why waste time with a system like XGP that will have a very small base?
 
Last edited by a moderator:
DaveC posted on Oct 31 2006 at 12:26 AM said:
HydraLancer posted on Oct 31 2006 at 04:28 AM said:
Like I said it’s a great system, but such as Zelda III was taken mid development to the Super Nintendo from the NES, I believe more can be accomplished with what’s around the corner.

-hydra

So since the game is scrubbed for the GP2X shouldn't you change your sig? It is kind of misleading.

Why wouldn't you do the game for the PSP or DS? Why waste time with a system like XGP that will have a very small base?

I would have hoped the hostility of the situation would not be passed to me because of Epicenter’s actions although I can see that that is unavoidable. If it makes you happy Dave I removed the signature.

The reason is because of ease, the average 2 person team I don’t believe can conjure up a DS game of this magnitude in there free time without the help of any other team members. I understand that some may have the homebrewing experience to create a DS or PSP game with the extensive knowledge of the hardware but realistically I do not think its possible without a team a programmers balancing things out.

Utilizing SDL is the main reason for this game to be for GP2X. Its ease and realistic format makes it great for making a great game with as little hassle as possible. If you were to go to DS or PSP territory it could take several people to make the same game effectively because of the troubleshooting required with the hard to manage languages and hardware spec. With this, the XGP or any other machine capably or running SDL is the more realistic choice for a 2 man or small team.

All I can say is that I apologize for any anger that may be floating about but I will carry on to the XGP as planned.
 
Last edited by a moderator:
JaqMs posted on Oct 30 2006 at 04:09 AM said:
If you have nothing constructive to say about the XGP's, stay out of the XGP FORUM.

Yeah, like you stay out of the gp2x forums?

The XGP will be too little and too late.
 
Last edited by a moderator:
Hmm, even if the XGP has hardware rotation/scaling/whatever, I doubt that when using SDL it will be significantly faster than GP2X at 2D stuff. If faster at all. You'd have to program for the hardware to take advantage of it in all likelyhood.
 
OK, first off, DaveC-- I apologize for my typo in a prior comment where I directed a little rant of mine to you rather than to its intended target, Craig. That was entirely a blunder on my part.

We chose the GP2X because of the ease of development in writing multiplatform code (on my part), lack of limitation on graphical aspects (screen resolution, color palette, RAM) and most of all, that it was not a 'closed off' machine that requires expensive hardware to get into developing for. I have extensive experience working with the C programming language so I chose it for the engine. SDL compatibility meant that it would be simple to perform testing on PC or other X86 platforms (e.g. X86 Macs), in Linux, Windows or other OS'es, and run the code on many platforms, and be assured of the same experience each time.

On PAPER the GP2X is a fine machine. It has a powerful ARM9 processor, capable of incredible accomplishments in game development. That sort of power on tap, with over 45 MB of free RAM to utilize, a 320x240 display and a massive color palette, and '2D acceleration' is an incredible combination. However, we began to learn the longer we went into the development process that things were not going to continue as smoothly as they began.

The problems I encountered did not stem from code efficiency, and we did not utilize Fenix or any other crutch, we worked from the ground up-- nothing else would be sufficient to take advantage of the system. My engine and all primary and secondary game logic ran at full speed with the CPU dramatically UNDERclocked below its 200 MHz spec. Problems began to arise where, when drawing the large and complex multi-layer graphical scenery, the blitter's weakness showed-- it was not truly a form of '2D acceleration', just the bare minimum-- and only added a few tiny boosts to the game's framerate. While I was able to maintain a rather staggering 140-190 FPS in my engine tests with a high degree of graphical complexity, problems cropped up one after the other. Memory bottlenecks and the intense load on the ARM920T caused by the mediocre blitter began to take a toll on performance when I brought things to the required intensity level. SD-DMA being fully broken resulted in long load time and the need for strange hacks to play audio. Attempting to run an audio decoding engine on the ARM940T cut performance in half instead of helping it. Strange crashes and sporadic unexplained behavior plagued the process and could not be repeated on any other platform. A lot of these issues might have been able to be worked around, with much aggravation, but two issues could not.

We approached a publisher who expressed interest in releasing our game commercially when it was completed. He bought a GP2X MK2 with the sole intention of playing our prototype versions. Upon getting the machine, he was disgusted. He said it felt like a cheap toy, the build quality was abysmal, and he wanted nothing to do with the system but to play our game on it. He has no interest in emulation of any sort and did not want to TOUCH the machine. This problem was compounded by that there was no documentation to indicate his need for high capacity NiMH batteries, so he believed the machine was broken until he bought an AC adapter, when it failed to boot/crashed repeatedly using Alkaline AAs. I and HydraLancer's confidence in the GP2X rapidly waned and it became more and more clear the probability of us releasing a finished game for the GP2X as an exclusive was more and more far-fetched.

The other issue was the stick, which you've all heard me speak out against before. It wouldn't be so big a problem if anything I worked on didn't feel unplayable using it. I found I had a perfect experience using a keyboard or a USB gamepad in my tests on x86 builds, while whenever I fired up the GP2X, I liked how most things ran and HydraLancer's graphics always looked spectacular, but everything felt wooden and clunky. I was, and still am, confident that I could work to help produce a masterpiece and it would still feel like an abomination and a waste of time, and I'd never want to show it to anyone anywhere but on another platform with acceptable controls. Anyone who tried it would pick up the GP2X and hand it back to me, saying "It's broken," when they tried to control the game. I cannot imagine anything more frustrating than being unable to control, and therefore enjoy, your hard work.

This isn't to say that we're giving up on our work, by no means is that true. However, we feel we have better opportunities with the XGP. When I spoke to Craig about a new machine tentatively planned for release by GPH after the GP2X, I gave him my input on what would make for the best development platform, a machine with superior 2D acceleration most notably, using Samsung's S3C2460 chipset. I was blown off, told that high CPU clock speeds were all that mattered because they are easier to market to people who like big numbers (a 'trucks with big engines' analogy was made) and my opinions refused, later resulting in Craig denying the whole discussion and sparking off the little feud you've seen come to a head in recent weeks.

I approached GP about how development of their XGP systems was going, and made the same suggestions I did to Craig; most notably the use of the S3C2460 instead of the VRender-3D since they wished to use more advanced hardware due to the delay time in developing the XGP series. They didn't blow off my ideas, they even stated they were already working on a platform using the very chip I suggested. They've even asked for my opinions and have been shaping the design of their systems to suit the desires of the persons who intend to buy the units, including this forum. Combined with their patient, more careful and methodical approach to design and prototyping of their consoles compared to the circus that was the GP2X's design/release, GP's approach is more confidence-inspiring, and we therefore believe the XGP/XGPmini will be a better target platform for our works.

Now, as I've stated, a big thing with me is compatibility and crossplatform code and graphical interoperability. I'd love to release a version that'll run on any PC built in the past oh .. 8 or 9 years, a Dreamcast version, a Mac and Linux compatible version, and possibly even one that'll run on the XBox, and it should be very easy to do so, and add enhancements for each particular version. For the same reason, I don't have a problem scaling back the final game to run on the GP2X, I just won't pour my heart and soul into it, and I can't really say I'd choose to play it on one if I had other, superior platforms to do so with.

It's not a matter of loyalty, it's not a matter of being on a 'team' for the GP2X or XGP or DS or PSP or PC or Mac or anything of that sort. A developer goes where his heart takes him, not where he feels he's bound with a chain. If you can respect that... thank you. You have a mature and sensible outlook. If not, that's your choice as well, but you will not accomplish anything by becoming angry over how we choose to express our full vision.

If you feel that's greedy in some way ... it's not. We may very likely end up releasing some incarnation of our work for free. We're not trying to get rich. It's flattering if someone is willing to pay for your mental emotional and physical investment in producing something that is truly fun to play and immersive, but it's not about 'striking it big' and selling 20 million copies of a DS game, and that's why we're not taking that sort of an approach.

My apologies if I've offended anyone on this forum with my behavior, but my patience with much of the input I've recieved, often rude, inconsiderate, ungrateful and downright vicious-- everyone can tolerate a certain amount, well, I've tolerated a hell of a lot, and beyond that point, it's quite difficult to stay rational. If you look through my post history, you can find my good days and my bad days quite easily. I'll do my best to be the person I've been complimented for being; e.g. informative and helpful. You likely won't see me posting in any GP2X section much at all in the future, I'm just not interested anymore. I'll continue to post here, but I'd prefer if it didn't invite personal attacks on me from persons like Craig.

That's all, and if you read this far, thanks. I appreciate it.
 
Iorgy77 posted on Oct 31 2006 at 01:50 AM said:
JaqMs posted on Oct 30 2006 at 04:09 AM said:
If you have nothing constructive to say about the XGP's, stay out of the XGP FORUM.

Yeah, like you stay out of the gp2x forums?

The XGP will be too little and too late.
Hypocrite. I only made one post in the GP2X forum in the past month, and it's just a joke post.
 
Last edited by a moderator:
Shame. I was looking forward to a decent shooter on the GP2X. Does anyone actually have even a ballpark figure when the XGP is going to be released? At the moment it does sound pretty good on paper but I highly doubt that will be the case in a years time.
 
Shame. I was looking forward to a decent shooter on the GP2X. Does anyone actually have even a ballpark figure when the XGP is going to be released? At the moment it does sound pretty good on paper but I highly doubt that will be the case in a years time.


Well Odonata is comming out.... :p

Ok just kidding.

I guess we will have to make do with shooters on GnGeo, SNES or Megadrive. There are some pretty good ones. Not as good as a native shooter I know but in a pinch they make do.
 
Last edited by a moderator:
Well like I said, we don't mind doing a GP2X version of Stargazer, albeit watered down to accomodate the hardware. I just wouldn't want to play it compared to another platform is all...
 
Well like I said, we don't mind doing a GP2X version of Stargazer, albeit watered down to accomodate the hardware. I just wouldn't want to play it compared to another platform is all...

Well I am not holding my breath for that. Not an insult just reality. Usually projects don't get finished for a system that a developer doesn't like. When your heart is not in it, it usually doesn't get finished.
 
Last edited by a moderator:
With the code and engine as portable as it is right now, a watered-down GP2X version shouldn't take much longer than an afternoon to get running. But it's just more a question of if I'd even want to bother if I was satisfied with performance on the XGPs and some other planned platforms, like the Dreamcast. Naturally it runs fine on x86 machines like the typical PC, and with a gamepad that's rather nice. :) I'll cross that bridge when I come to it, I suppose.

I can't see myself giving the GP2X much regard in the future, though. It was a fun toy to play with, but I just got a DS Lite and it's proving to give me a lot more entertainment overall. There's a fantastic selection of emulators for it, including better SNES emulation than the GP2X can manage to pull off at the moment, MegaDrive emulation that's very satisfactory, SMS/GG, GB, NES, and quite a few others, as well as the ability to do some rather nice video/audio playback and image viewing which occupied a lot of the time I spent using the GP2X. It's a more balanced machine since all its resources aren't poured into a fast CPU and another fast-but-useless CPU, instead a snappy CPU, a useful coprocessor (ARM7TDMI) and excellently designed video hardware. I don't really understand the people saying the GP2X has a better screen than the Lite-- these are brilliant. Brightness level's not how I gauge quality anyway... but if it was, the Lite's highest setting causes my eyes physical pain. :lol:

I don't intend to develop for the DS, but I have to say, if it weren't so much work to do so, I'd like to. However to get the best results out of a machine with its configuration, it'd mean writing lots of ASM (big pain), tackling weird issues exploiting peculiar hardware (Nintendo is famous for weird design, their 2 arguably most famous systems, NES and GB, had sound generators integrated into the processor).. plus my code would never run on anything else but an emulator, and that's troubling. Systems supporting SDL mean I can spend less time worrying about how to display graphics and play audio, and more worrying about how much fun you can have with the game.
 
I don't intend to develop for the DS, but I have to say, if it weren't so much work to do so, I'd like to. However to get the best results out of a machine with its configuration, it'd mean writing lots of ASM (big pain), tackling weird issues exploiting peculiar hardware (Nintendo is famous for weird design, their 2 arguably most famous systems, NES and GB, had sound generators integrated into the processor).. plus my code would never run on anything else but an emulator, and that's troubling. Systems supporting SDL mean I can spend less time worrying about how to display graphics and play audio, and more worrying about how much fun you can have with the game.
Look at palib.
 
Last edited by a moderator:
There's a fantastic selection of emulators for it, including better SNES emulation than the GP2X can manage to pull off at the moment, MegaDrive emulation that's very satisfactory, SMS/GG, GB, NES, and quite a few others, as well as the ability to do some rather nice video/audio playback and image viewing which occupied a lot of the time I spent using the GP2X. It's a more balanced machine since all its resources aren't poured into a fast CPU and another fast-but-useless CPU, instead a snappy CPU, a useful coprocessor (ARM7TDMI) and excellently designed video hardware. I don't really understand the people saying the GP2X has a better screen than the Lite-- these are brilliant. Brightness level's not how I gauge quality anyway... but if it was, the Lite's highest setting causes my eyes physical pain. :lol:

All of the emus on the DS except for Speccy or SMS are crap, especially Megadrive. There isn't enough screen resolution for them so it looks like shit no matter how smooth they may be. How do you display 320 x 220 on a tiny 256 x 192 resolution screen, eww.

That is probably why we may say the screen on the GP2X is better than the lite, it actually is a decent size and has enough resolution to display emulators better. The M2 is better than the M1 which is kind of washed out and flickery. The Lite has brightness and good color.

The DS is good for original native stuff, although I wish the screen, at least one of them, was bigger. Even the GP2X is getting to the point where it is a bit small. 4" 4:3 would be great.

I have a DS lite by the way. It is nice, it has some good original stuff for it.
 
Last edited by a moderator:
All of the emus on the DS except for Speccy or SMS are crap, especially Megadrive. There isn't enough screen resolution for them so it looks like shit no matter how smooth they may be. How do you display 320 x 220 on a tiny 256 x 192 resolution screen, eww.
Looks good enough to me. I care more about the quality of emulation, not the screen size and aspect ratio. I'll say it again, emulation is imperfect so I don't expect a perfect display. Having a system that can emulate machines that near-perfectly match its resolution like the GP2X and MD/NeoGeo emulation is extremely rare, the closest common platform would be PDAs where you need to rotate the 240x320 display for something reasonably appropriate, and the quality of the emulators are quite bad.

I'm impressed with the performance of many of the emulators for the DS. The most popular SNES emulator shows much better performance than SquidgeSNES or NKSNES since it utilizes the DS' 2D acceleration for the strenuous task of the SNES' VDP emulation, handles audio on the ARM7TDMI, etc. Raw CPU emulation is impressive as well, with Starfox (which had a tough-to-emulate 'SuperFX' polygon processor onboard to emulate) running at framerates about matching the original. MD emulation doesn't look quite as fast as on the GP2X, but for a 67 MHz ARM9, that's quite impressive. The upshot is that the emulators for the DS are more efficient and more highly optimized for the hardware. The GP2X's emulators are mostly modified and optimized ports from other platforms with a lot of non-platform specific C code that bogs them down (SNES, NES and Amiga emulation being the worst culprits at this point in time.) I've never been about the graphics, rather, the gameplay and intensity of that gameplay, via speed, is what must be maintained. If the screen is scaled so it's not pixel-perfect, I can live with that. Real consoles scale their output via analog means to display on TVs anyway.

At any rate I am more interested in the original software, really... though I like the prospect of media playback on the unit as well. The PDA functionality added by the M3 adapter is also a fine bonus, and web access with homebrew browsers over the WiFi connection is a fun bonus. Thanks to the proper GPU in the DS, Quake is running quite nicely already and shows considerable promise; it bests the GP2X with a heavy overclock in most points and the 2nd display allows not only a great view of the console (great for a developer like me who builds games based on the Quake engine, a big reason I got the GP2X originally) but also allows very intuitive and accurate control via the touchpad for looking about and aiming, something that feels clunky and awkward with the GP2X's stick, an analog stick or a d-pad. Doom and Wolfenstein 3D are also running VERY nicely. It's an all-around excellent package, really.
 
Last edited by a moderator:
Real consoles scale their output via analog means to display on TVs anyway.


Stop saying that, it is not the same as "scaling" on an LCD. Consoles do not "scale" on TVs they just alter the beam scanning rates slightly to fill the screen, the pixels are still evenly displayed (the same size relative to each other), and all of them are displayed. Scaling on an LCD either removes whole pixels meaning missing detail, or adds extra ones in places (meaning pixel size is not the same relative to each other) to make up for extra screen area.

Scaling down, which the DS does most of the time for emus, is the worst kind of scaling because you are losing detail. Text looks extra bad.

You keep saying that removing pixels is Ok on a handheld because TVs resize the image. It is totally different, it looks different, it is different. It is a bad rationalization. Whether you mind or don't mind is a different story.
 
Last edited by a moderator:
Regardless of the method by which it is done, analog or digital, the end result is an image of a different aspect ratio than the one at which it started. If you really can't stand that so much there is usually te option to display just part of the screen, like NES emulation, where you can just include the part where the real action is at. Or for systems with a LOWER resolution, just display it 'letterboxed'. I'm sure you find both practices appalling and unacceptable, however.

Whenever I worry I'm too much of a perfectionist, I just thank myself I'm not you, DaveC. If I was that picky, I could never enjoy anything. Do you enjoy that sort of mindset? It'd drive me nuts to be that selective.

Orkie said:
Look at palib.
It's quite interesting, although since the code I'd produce for the DS would be completely unportable I couldn't see myself using it. The resolution is also rather nonstandard, and that's what we'd have to adapt sprite size for, which would screw with platforms that use larger resolutions like 320x240. Also I'd hate to screw with all the memory juggling work that no doubt will arise from the ~4MB of RAM available on the DS.

Also, PAlib likes to do things like scrolling for you; I prefer to write all my game logic code from the ground up like scrollers so I know exactly how it works internally. If there is any code I didn't write it's well documented as ANSI C or SDL functions/defines/data types.
 
Last edited by a moderator:
Back
Top