EasyCE 2.0

[Digby]

Regarding the lock/unlock paradigm, similar to what DDraw does, you can lock only a subrect of the surface.  That will keep you from having to rotate the entire surface.  Using the read_only or write_only flags can also eliminate the need for one of the rotations.<br><br>My 2D code doesn't need to touch the raw pixels on a per-frame basis, but my 3D rasterizer sure does.  In that case, the rasterizer works with a back buffer that is oriented the same as the primary surface.  It works out well because on the iPaqs I just append another transform that rotates the vertices into landscape orientation.<br>

[suchiaruzu]

Wow, you guys are really talking professional stuff! If everyone at PM was like you<br>a) We would be the leading Developer board<br>b) I wouldnt understand a word <br>Great job boys!

[Phantom]

Aw come on, we (PM as a whole) ARE the ultimate coding board. Everyone plays PocketQuake, everyone uses EasyCE, everyone waits for Argentum. <br><br>Back to Digby and the other coders: I've uploaded a small document describing the current plans. I'm implementing them right now, but finishing them will take more than just tonight. I'm starting to like the idea of the three modi, it's comfort for starters and pure control for pro's. Can't beat that.<br><br>O yeah, that doc is here:<br>http://www.pocketmatrix.com/phantom/design.txt<br>

[cryo]

hey,<br><br>about the GDI stuff, i think its a very cool idea. i would suggest doing it like it is done in directx, namely providing a GetDC() and ReleaseDC() method, and warning the developer that it will be very slow to use it <br><br>cryo<br>

[Dan East]

As Digby suggested, if instead of malloc'ing your bitmap arrays you use CreateDIBSection, then when the user wants a DC to draw to, you just CreateCompatibleDC, then select in your bitmap handle. Other benefits include the ability to fall back to Windows API for blitting out to the display, and emulator support. Everything I do in the Pocket PC emulator on my 300 mhz laptop with BitBlt to output to the window's DC is still faster than GAPI with my iPaq.<br><br>Dan East

[Hosed]

If I recall correctly, isn't Quake and/or Doom Triple buffered?  Obviously speed comparisons don't apply, just thought it was an interesting note. Dan would obviously know if this is true or not.<br><br>I personally don't much care for GDI, but Dan makes a good point, for Emu support it's the way to go.  For my own uses I've just ported my libraries over to DirectX/Win32 and have a little PC based version of my game that I can test on.  Combined with my modified asserts it's worked fairly well so far.  I had other reasons for going that route though.<br><br>Also, I recommend using TCHARs instead of CHAR*.  tchar.h I believe.  It's what all Win32 programmers use to support unicode and ANSI seamlessly.  You do still have to use the TEXT(), _T() macros, but that's a good thing in my opinion as it means you're truely platform independent in regards to unicode then.<br><br>-Hosed <br>Last modification: Hosed - 01/02/02 at 23:51:45

[Dan East]

Not to my knowledge. WinQuake was using some 3rd party library for its Windows drawing, etc. It may have been triple buffered, but I didn't really look into it. I just chopped all that out and replaced it with my GAPI code. I take the main palettized bitmap and blit it out to the hardware, looking up the color values in the palette along the way. Quake2 handled all the Windows stuff itself.<br><br>Dan East

[Rudi]

I've just read your plans for EasyCE 2.0.<br>I'm currently creating some C++ classes over the pure EasyCE1.6 functions.<br>Currently it has:<br>- ImageLoader class (TGA TGAZ)<br>- Surface class (target of draw and blit operations)<br>- Screen object (representing the device screen)<br>- Sprite class supporting:<br> o MIRROR_X/Y,ROTATION,R,G,B-FILTERING, COLORIZATION,GRAYSCALE,OUTLINE,ALPHABLENDING<br> o Supports several images for a single sprite (ie:ImageLists)<br> o Destination to any Surface object (not just the main screen buffer)<br> o Adjustable clipping rectangle<br>Planned:<br> o palettized image loading and support<br> o displaying sprites with false coloring<br>- FontWriter class<br> o Support for bitmap fonts<br> o Color support<br> o Fixed and proportional display (from the same<br>   font data)<br> o Adjustable spacing<br>Planned:<br> o Word wrapping<br> o Line justification<br><br>An animation class is also in work (using the image list support of the Sprite class)<br><br>If it's intersting, I'm offering it as a starting point/prototype/source for ideas or whatever.<br><br>Regards, Rudolf

[Phantom]

Sounds like cool stuff. Looks like we have some overlapping features though. I implemented the skeleton of the surface stuff; I can now instantiate 4/8/16 bit surfaces, either landscape or portrait, and tonight I'll be able to convert between them (using slow default copiers, specific format-to-format converters will be added as needed).<br><br>Once the surface stuff is good enough I'll start adding handy things like sprite code, MikMod, Zlib and so on. I'm very interested in your sprite code, btw, sounds like quite a bit more advanced stuff than I had for 1.6.<br><br>I hope to have something to show ASAP (one week or so), after that we should really discuss how we can share our efforts. Especially now that everyone seems to be doing coding libraries. Frogs.

[Dan East]

Anyone see the "PocketFrog" game library as reported on PocketGamer? Sounds like someone has been reading these threads...<br><br>http://www.pocketgamer.org/archives/00000720.shtml<br><br>Dan East

[Dan East]

Now that I followed the link I posted, I see you have, Jacco! <br><br>Dan East

[Digby]

YAGA (yet another gapi abstraction)<br><br>It's interesting to read the features of the PocketFrog library.  You'd swear the guy generated that list directly from our discussions here.<br><br>Jacco's right, there seems to be a dozen people working on different libraries for some reason.  I don't really get it.  I'd be happier if these folks spent their time writing games instead.  (Jacco, you're off the hook here because you've actually shipped games using your lib)  <br><br>Here's a theory, maybe these guys write libraries instead of games because they have trouble producing content for a game?  Maybe one day when we get tremendously bored we could cajole a few of the more artistic members of PM to produce a dozen or so animated sprite characters, then have a contest against the bitheads here to write a game using those characters.  It could be any genre of game, the only requirement would be that you'd have to use those sprites and have it run on the current crop of Pocket PC devices.  Might be fun.<br><br>

[danyblue]

Hi all,<br>I don't agree with Digby in his affirmation regarding the developpers of new libraries for the PocketPC plataform.  With new libraries, new ideas will come to scene, new functions will be implemented, and the end, programmers who develop games will have better tools to do their work. <br>In the case of the author of pocketfrog, he is also the author of the emulation gapi tool that exists, and that a lot a people works with, his frog library exists from some time now, but not for the pocketpc, and he has simply ported it and updated to new requirements.<br>Notherless, i agree that to much libraries will bring disperstion, and a lot of work will be leading to no where, but then may all is just a question of grouping the pocketpc developpers into groups instead of individual work.<br>In the linux community, all the major developments are distributed through teams that worldspread, instead of doing their lonely coding in the night...<br>I know that,because since I am trying to port the Allegro library to the PocketPc, i didn't received any solicitation to participate in the project.<br>I think that we are still in the infancy, and we must learn a lot with other communities which are a lot more organized and developped than ours... But then?Maybe in this environment (pocketpc) is orientaded in soon or later, create somekind of company and earn money from , and not create opensouce quality software.<br><br><br>regards,<br>Danyblue

[Zensunni]

Phantom:<br><br>easyCE 2.0 sounds extremely good <br><br>I'll definately make easy3D as an addon to that, and not go with own stuff. You are right concerning library development, there is no point in reinventing the weel, and easyCE 2.0 seems like it could be the ideal starting point for extension..<br><br>

[Hosed]

In response too to many libraries, yeah, there's a lot of public ones being developed.  I myself am writing my own as EasyCE didn't meet the needs I wanted when I started my project and I'm so close to being done now that I see no point waiting for others to finish their own.  That, and mine was never intended to be public, though that may change if I feel there's an actual need out there.  With EasyCE 2.0 and other libs though I highly doubt people would want a lib that was aimed at more specific requirements.<br><br>-Hosed