EasyCE 2.0

[Phantom]

I'm considering to start on EasyCE 2.0, because EasyCE 1.x is rapidly becoming a dirty pile of handy tools (perhaps it always have been a dirty pile of handy tools ).<br><br>Anyway, here are some basic ideas that I would like some feedback on before I start:<br><br>- EasyCE 2 will be initialized in the same manner as EasyCE 1.x, using a winmain in the library and a main in the application that you write. This way, I don't force anyone to use C++ code (except for some classes); one year ago that would have been reason enough to skip such a library for me. <br>- Instead of a pointer to the frame buffer and stuff like that I want a surface class that defaults to 240x320. That way, you can simply create a new surface, instead of a PIXEL array, if you want to swap screens or whatever. Copying from one surface to another would also require far less parameters and stuff like that. Would be generally better. The framebuffer would in that case be a special case surface.<br>- Surfaces can be 'rotated'. The hardware framebuffer of the iPaq is an example of this. Allowing this for all surfaces also makes it possible to use a 'rotated' temporary buffer (currently the 'internal EasyCE buffer') so that the app runs better on ARM devices (wich seem to take the lead at the moment), while still supporting MIPS.<br>- EasyCE 2.0 will come as a .lib instead of a .cpp and .h. That way, EasyCE can consist of multiple sources, wich will improve the maintainability.<br>- EasyCE 2.0 will be completely free.<br>- PC support will stay.<br>- 3D stuff will be added; initially my fixed point matrix and vector stuff plus basic polygon rasterizers.<br>- MikMod and ZLib will be added. These are libraries that you simply 'need'. I'll encapsulate them so that they can be replaced by alternatives when anyone feels like it without breaking apps that use EasyCE.<br><br>But the surface class is the most important thing. It would make things Easier, IMHO.<br><br>What do you guys think?<br><br>- Jacco.

[Dan East]

If I understand #3 right, does that mean the backbuffer(s) can be rotated to match the native orientation of the hardware, so final display blitting can be performed in alignment with the scanlines? That would solve the smooth-scrolling issue I mentioned in another post (with landscape-hardware), without incurring the cache-thrashing penalties.<br><br>Dan East

[Digby]

I use a lock/unlock paradigm on my surfaces (similar to DDraw) that allows me to "swizzle" the surface data to any orientation necessary so that when the surface is blitted it will always be a sequential memory copy and won't have to perform a row/column translation.  The rotation occurs during the call to unlock.  This works well because the locking/unlocking is only done when I load the image from disk into the surface.  I don't do any raw pixel access on a per-frame basis - just blits.<br><br>In case you're wondering there is also a rotation when the app locks a surface, since the surface is typically stored in a format unknown to the app.  This "swizzling" can be controlled by the app though.  The lock and unlock calls have parameters that let the API know if the data will be read-only, write-only, or read/write.  Those flags determine whether or not a swizzling must take place.<br><br>Of course if you're running on a native portrait display none of this would be necessary, however this library supports any screen orientation and would have to swizzle if you wanted to display, say, landscape on a native portrait device.<br><br>Anyway, that was a bit longwinded and probably confusing.  I hope at least Dan and Jacco understood it.  What I tried to do was to minimize the work necessary to perform blits and flips (back to front buffer copy) since they are done each frame.  Spending a bit more time in the loading of a surface to do the rotation once seemed like the better way to go.<br><br>Hey do you guys know if the newer ARM-based PocketPCs have their displays oriented like the iPaqs?  The landscape orientation isn't just an ARM thing, is it?<br><br><br><br>

[billcow]

I think I read somewhere that all the new ARM devices also have rotated framebuffers. I also agree about the "dirty pile of handy tools" (especially the handy part)<br><br>Anyway, I think that a surface class is a good idea. I like the idea of a Lock/Unlock to ease the conversionn from rotated/unrotated, but maybe that could be part of a subclass. A few extra things it could have are palletted mode (If I write a program with a pallette (like a demo effect), I have to store a whole extra temporary buffer, which could be eliminated if the conversion was in the blit to the screen. It could also help on palletted devices).<br><br>I also think that there should be more options to leave stuff out at compile time, for smaller exes.<br><br>You should also have optimized line/box/etc code, possibly even some assembly routines (probably would only be for the ARM, since that's the only one the new PPCs have, and the relative difficulty of assembly code). You should also have code for different types of tga files, and transparent conversion between them. Maybe even have a constructor for the Surface class that creates it from a targa. Some STL type stuff could be useful (linked lists, trees) seeing as how eVC left that out. (of course, you could just tell people to use the port for WinCE, but your version would probably be faster and less "crufty" (tm))<br><br>About the anti-c++ people , maybe you could have a non-c++ function to update the screen using a EasyCE 1.x style PIXEL array. You could also have a similar "PlaySnd" function that would play raw sound data in an array.<br><br>It would be nice if you could add back the ce 2.1x support, I've already gotten two requests for Ce2.1x versions of one of my programs (and I just released it on monday).<br><br>For libraries, the source code would still be available of course, right?<br><br>Oh, Digby, I understood you perfectly well about the Lock/Unlock thing.

[sillycat]

yea! finally in C++ !<br><br>erm... the lib better be separated by functionality, incase someone only want the graphics without sound... and some may have his better sprite handling routine..Last modification: sillycat - 12/29/01 at 17:55:25

[MirekCz]

C++? gosh didn't Carmack Quake2 source teach you anything?;P (and no, I don't mean that his code is unreadable...)<br><br>To be honest, I simple don't get all that C++ stuff so I prefer C:) going to read Stroustrap book in short future thru so I might understand it better;)

[Phantom]

Thanks for the suggestions so far!<br><br>About the surfaces: My latest thoughts on this are like this: There is one special surface, that is the framebuffer. That one can be either portrait or landscape, landscape on all ARM devices. In my latest plans, this surface can't be written to using drawing primitives, it can only be updated by a call to 'update' (or something similar).<br>All other surfaces can be protrait or landscape: If you choose to have them all landscaped, the app will run faster on ARM PPC's (since the 'update' doesn't require rotation); portrait surfaces work faster on MIPS and SH3. Currently EasyCE uses only portrait since the slowest devices handle this more efficiently; the idea was that this would guarantee a more equal performance on all devices. With the large market share of ARM devices, it now seems more logical to aim for ARM devices and have MIPS / SH3 support as a 'nice to have'.<br>Since you will still be able to use primitives and pixel operations on surfaces, this means that either the app supports landscape or portrait (note that you can use landscape to draw a portrait image, of course, it's just the orientation of the buffer), or perhaps an application programmer chooses to support both (wich means double code for some things, but faster performance on all devices).<br>So, the 'primary surface' (the framebuffer) doesn't accept lines, plots and so on. Other surfaces do however, so all the current EasyCE drawing primitives will be methods of the surface class.<br>A call to 'update' will thus detect wether or not the source and / or destination surface is rotated, and it will convert if neccessary.<br><br>So far for my ideas. About palettized surfaces: This is an excellent idea. It would be very cool to be able to load a palettized tga and keep it palettized in memory; this saves a lot of space. A palletized surface will of course have a different set of drawing primitives (also palettized), and I don't think it will be possible to copy (part of) a 16bit surface to a palettized surface, unless the target is the primary surface (on 8bit devices).<br><br>About excluding parts of the library to keep EasyCE small: I was thinking about having a 'core.lib', containing the surface stuff and some more generic things (probably also the tga loader / saver wich is rather generic IMO) and besides that a '3d.lib', 'audio.lib' and 'game.lib' (containing the actor stuff, a.o.). That way you can link whatever you need.<br><br>Besides the surface class I'll also need a 'core class' that handles the mouse stuff, buttons, timers and so on (I want multiple timers this time). I'm not yet sure how this class will be instantiated; I think it must be created by the 'winmain', and after that you can retrieve a pointer or reference to it by calling 'getcore' or whatever. This could have been avoided by making EasyCE an application framework that you extend; as I mentioned earlier I don't like that approach since it's too 'C++'. <br><br>One more thing: I want sprites. Not like I did them in EasyCE 1.x, but I want to simulate a display that supports sprites natively. I think I'll attach them to the primary surface; when you call 'update', EasyCE will then first draw the sprites to the primary surface and then draw it. Pitfall: On some devices, modifications to the framebuffer are immediately visible, while on others, a call to 'GXEndDraw' is needed. So perhaps I should attach sprites to surfaces instead, but that would change the surface (you can't remove the sprites without refreshing the entire surface). A solution would be to have an internal backbuffer in the same format as the primary buffer, but that would slow down EasyCE. On the other hand, ARM devices don't need that, so performance would again be better on ARM than on MIPS and SH3... So the sprites still need some thought.<br><br>I would also like to add a C-Buffer to at least the primary surface. If you don't want to use it, you won't know it's there and it won't eat any performance. If you know how to use it, it can speed up some sprite operations (of simple sprites) and it is absolutely needed to speed up polygon rasterization.<br><br>Well enough babbling. I would really like some comments on the sprite issue. Perhaps I should forget about it and do it just like I did it in EasyCE 1.x.<br><br>Oh yeah one more thing: In ARM asm you can load multiple registers from memory with a single command. This could be used to get 24 pixels at once from the source surface and plot them on the primary surface. This trick could probably speed up the rotation significantly, and it is quite simple code to write. Just an idea.<br><br>- Jacco.

[Digby]

Jacco if you're crafty enough, you can allocate the memory for your surfaces via CreateDibSection, and select the resulting bitmap handle into a memory DC.  This allows you to return an HDC to the user and they can do things like draw lines, circles, ellipses, fill rects, and use TrueType text (all with varying ROPs) into the surface using GDI APIs.  You won't want to do this for every surface because of the memory overhead necessary for the GDI objects, but you could offer the user a flag at surface creation time as to whether they were going to be using GDI with the surface.  Just a thought.<br><br><br>

[Phantom]

Hm, I think the truetype text would be nice, but the rest of the stuff is not exactly what GDI is famous for... Besides, Windows is something I'm trying to evade. Think mode 0x13h.

[Phantom]

Does anyone know this: Does the address that the PocketTV dudes mentioned for framebuffer access on the 3800 also work on the 3600's? And, related to that: 3600's don't update the display until I issue a GXEndDraw command, if I'm right. That suggests the use of an intermediary buffer. Can that be prevented using the 'PocketTV address'?

[Digby]

The 3600s don't use an intermediate buffer.  The address returned by GXBeginDraw is 0xAC05029E on my 3670.  That is the address of the 0,0 pixel in portrait mode, so the actual start of the display buffer is 0xAC050020 (pixel 0,319).<br><br>The iPaq 3800 address is 0xAC0755A0.  This is the address of the pixel 239,0 in portrait mode.<br><br>Hope that helps.<br><br>BTW, GDI is famous for providing a full set of 2D graphics drawing APIs for millions of programmers for well over 10 years.  It is both a well-documented and well-understood API (certainly moreso that mode 0x13).  The additional work necessary for you to provide an HDC to your surface is minimal.  It would keep you from hearing things like, "Jacco, please implement TrueType text..." or "Please consider adding support for drawing circles and ellipses" or "Please write a image loader for bmp, gif, jpg, etc.".  You get all of this for free with GDI and THAT is what it is famous for.  I don't see how you can lose by adding support for these things.  We're only talking about an additional dozen lines of code.  However if your #1 mission is to evade Windows rather than provide useful features then you've made the right decision.<br><br>

[Hosed]

Correct me if I'm wrong, but for landscape surfaces you could just rotate the image on load (as previously mentioned and done I believe) and, as long as the frame buffer is 320x240 (in landscape orientation) then all one has to really rewrite is the flip routine correct?<br><br>If that's the case, then I'd just have a portrait flip and a landscape flip and a portrait load and a landscape load (for artwork).  Maybe that'll take to much work on the user end though since you're writing a lib.  I don't know.  Just a thought.  Unfortunately I have yet to buy an iPAQ so I haven't played with the whole portrait to landscape issue.<br><br>I like the palettized image support.  In fact, it's something I implemented in my own libraries not to long ago.<br><br>Sounds like EasyCE is quickly turning in to what I've been doing with my own libraries <br><br>-Hosed

[Phantom]

No intermediary buffer on the iPaq? Hm, that means that I probably need to assemble a temporary buffer in landscape format with the rotated framebuffer and the sprites in it. That's still one 240x320 memcpy extra compared to EasyCE 1.x... I'll need to time that memcpy to see what the penalty is.<br><br>About GDI: Please forgive me, but indeed, I do like to evade Windows. What you mentioned does sound cool however. It would indeed be nice to at least be able to do things, even if *I* don't plan to use them. Perhaps you could add this GDI stuff? It would probably take you far less time than me...<br><br>What do other coders think about this GDI stuff? Do you need it?

[Digby]

Jacco,<br>If I understand you correctly, it doesn't matter if you provide the back buffer or if the particular display buffer does...  there will still be an additional copy taking place as the data is copied from the intermediate buffer to the primary surface.<br><br>Hosed,<br>If you use a back buffer that is oriented the same as the primary surface, and then you rotate the source content (sprites) when loaded, you don't need to rewrite the back buffer-to-primary update routine as it becomes a single contiguous copy operation.  You do have to adjust the Blt (x,y) position of the sprites to handle the rotation though.<br><br>

[Phantom]

Digby,<br><br>Problem is; EasyCE 1.x lets you copy a freely accessible 240x320 buffer to the hardware frame buffer. That results in some nasty effects: Sometimes scrolling is a little jerky because of this. The only solution would be to use a third buffer that is used to draw the rotated image in (plus sprites), wich can then be copied in the fastest possible way to the hardware framebuffer. That should virtually eliminate the jerkyness.<br><br>However, desprite how good that is for all sorts of things, it's slower. And that sucks.<br><br>How about this: I offer the game programmer the choice: Either he uses a 320x240 buffer to hold the final image (rotations (if neccessary) and sprites) - This buffer would thus be the 'primary surface' and the hardware framebuffer would be 'hidden' to the programmer; OR he looses sprite support and accepts jerkyness, with the advantage of the raw speed of EasyCE 1.x (or even better, since you could use a 320x240 buffer in your game, so that the rotation could be skipped).<br><br>This 'choice' needs a good API, of course, and one of those needs to be the default modus of operation. The sprite + 320x240 buffer approach seems to be the most logical 'default modus', as it's really cool for most games.<br><br>One other thing: I gave the lock / unlock stuff some thought, but I think it's not going to work for EasyCE since I really want free access to the pixels of the surface. Perhaps some coders like to work with blits and primitives, but I like raw access. All my games write to the frame buffer quite randomly in every frame, so a lock / unlock feature like you described would effectively result in TWO rotations per frame. That doesn't mean that the lock / unlock stuff is bad, it just doesn't fit in with my coding style.