EasyCE 2.0

[Phantom]

I just noticed on PocketGamer that there is a new 2D library named GapiTools. The lib looks so good that I need to seriously look into it before I decide whether or not it's worthwhile to continue developing EasyCE 2.0. So if anyone spots anything in GapiTools that could be better, please post to this thread... So far, I see a couple of potential problems:<br><br>- The MFC stuff (I don't like MFC)<br>- The lib only supports ARM<br><br>But that's about it. The thing looks very fast, and seems to offer everything you could possibly need.<br><br>About EasyCE 2.0, I have implemented the core: 6 surface types: portrait & landscape surfaces in 4/8/16 bit. The base surface class can now convert between these formats, but that's implemented using a slow generic approach; for optimal performance I would need 36 converters, 6 per surface type to convert to all surface types. Of course, we could implement only the most often used ones first.<br><br>Before I start implementing those, I want some more functionality; I'm working on sprite support right now. That's a lot of work: Sprites draw from a surface to a surface. That means: 36 sprite routines... Right now, I intend to skip a couple: The source surface for sprites can only be 8 or 16 bit, and must be landscape. This reduces the number of sprite routines to 12, wich is still an aweful lot.<br><br>That's why I am considering dropping the project, it looks like it's going to be too much work.<br><br>Any ideas / encouraging words? <br><br>- Jacco.

[Zensunni]

and after a first short look it looks like the sourcecode for the actual library is not there, he ships it as a library..<br><br>i don't like that..

[Zensunni]

and after a first short look it looks like the sourcecode for the actual library is not there, he ships it as a library..<br><br>i don't like that..<br><br>and no grayscale/8bpp colour support, and only arm processors..<br><br>i don't like that either Last modification: Zensunni - 01/09/02 at 08:41:42

[GeoffSulcer]

Phantom,<br><br>I, for one, would most certainly hope you continue to work on EasyCE2.0  I've been using EasyCE for a few months now and your plans for 2.0 sound like they will provide some very nice things that I don't have currently.<br><br>There are three main reasons I chose to work with EasyCE versus other tools:<br><br>1.  Platform-specific stuff is done.  I don't have to worry about it (much).  In other words, even though I only have a Casio E-125, I can develop code and have a (reasonable) chance that it will work on other devices as well.  Therefore I spend more time on the game/app code.<br><br>2.  Microsoft Windows and GAPI stuff is done.  I'm not a fan of the Windows programming model, especially MFC.  But, I do know C/C++, so having a main function and routines that handle the buffer and keypresses are just what I want.  Again, I spend more time on game/app code.<br><br>3.  It's free and I can make changes to the source when I need to.<br><br>So, unless you were planning to do away with any of those three, my guess is 2.0 will still be my choice.  And, I'm betting that there are others that feel the same way.<br><br>Plus, I still use my Casio (MIPS) so anything that is ARM specific is useless to me.<br><br>Maybe you can just implement a few of the most commonly used converters and when you release it, some of us in the community can add in the rest as needed.<br><br>Anyway, keep up the good work, I look forward to 2.0 and more tutorials!  <br><br>-Snork

[Digby]

Jacco,<br><br>You should do what makes you happy.  From what I've seen, working on EasyCE does make you happy so that work should continue.  As far as justification for your work: I would think there are enough people out there who don't want to use MFC that would like to use your library.  Besides, you already have a version out there that some people are using.  You've also got this great support forum for EasyCE here.  I would think people aren't too keen on the GAPI Tools startup logo being shown everytime you run your app either.  Libraries like this will continue to be released.  Some day (and soon from what I've heard) Microsoft will release a DirectX implementation for the Pocket PC.  At that point, most of the support for these YAGA libraries will wane.<br><br>I went to the GAPI Tools website and read this in their FAQ:<br><br>Q: How did you get that kind of graphics speed in all screen orientations?<br>A: GapiTools uses advanced pixel translations, and always transfers as many pixels as possible in chunks using 32-bit memory transfers. All bitmaps are converted to match the native screen format once they are loaded, and they also have to be recalculated each time the screen is rotated. All code is assember-optimized inline C++, and it has as much redundancy as possible to improve operating speed. <br><br><br>Gee, the part about loading the bitmaps and rotating them to the native orientation sounds really familiar...<br><br><br>

[Phantom]

You're right about the native orientation stuff. <br><br>About EasyCE: I'm a bit confused at the moment. The big issue is not the 4/8/16 bit stuff; ultimately, there will only be 16bit landscape stuff. Or even more ultimately, there will be arbitrary sized buffer stuff at arbitrary bitdepth, with 3D acceleration. But for the moment, 'boosting PPC game coding' needs something more down-to-earth. The big issue is, IMHO, do we stick with the intuitive portrait orientation, do we permanently switch to landscape, or should we postpone a decision by offering surface rotation? Let me explain that: Rotation is a slow and basically unneccessary process that makes things harder: You can easily provide drawing primitives that make a landscape surface look like a portrait surface, but as soon as a user asks for a pointer to pixel data, you either start rotating (basically wasting time), or you confuse the user.<br><br>Perhaps I should never have started on that stuff. Perhaps EasyCE 2.0 should do what EasyCE 1 did: Offer a canvas that is the same for all devices, but this time a landscape one. An update will copy it to the iPaq frame buffer, or rotate it to the Casio frame buffer. That way, the strong become stronger, while the weak can temporarily join the fun, at a reduced speed. Later on, we drop portrait support altogether.<br><br>Right now, doing a sprite engine that supports all those surface formats just doesn't make sense. The best solution would be to make one generic sprite engine that handles all surface formats. That way, once 640x480 PPC's appear, the sprite library is still useful. Same goes for 3D stuff, drawing primitives and so on.<br><br>There are some things certain, IMO: Such a dedicated sprite library would be valuable for at least 3 more years. I think the PPC form factor / screen resolution will be used for at least that long. 3D acceleration won't be with us soon, meaning that 2D stuff will always be interesting. FPU's won't arrive soon, making 3D acceleration even less likely (what would a GeForce be without an FPU? ) - So a generic software rasterizer would be interesting. In fact, I think I'll focus on that for a while. <br><br>I'm really interested in your opinions on these matters. I'm going through a bit of an identity crisis right now. In short: GapiTools looks awesome and unbeatable, but I'm rapidly becoming a 'rotation maddness skeptic'.

[GeoffSulcer]

[billcow]

[rudolf]

[danyblue]

[Phantom]

[rudolf]

[Phantom]

[Digby]

[golan_trevize_x]