GapiDraw 1.1 : April 18

[Johan]

GapiDraw 1.1 release date: April 18

[Updated 2002-04-14]: I have had lots of work with my research activities lately, forcing me to postpone the release date of GapiDraw 1.1 to April 18 (this Thursday). Casio support is fully functional, and I am working through the bug reports and tweaks now.

Additions:
(1) (Idea from Jeff @ CapesDev) Constant opacity support in AlphaBlt and AlphaBltFast.
(2) (Idea from Sam Nova) More screen resolutions for stationary PCs (GDOPENDISPLAY_X2=640x480, GDOPENDISPLAY_X25=800x600).
(3) (Idea from Sam Nova) New return code from OpenDisplay: GDERR_UNSUPPORTEDMODE if 16-bit mode is unavailable.
(4) Correct window alignment on stationary computers when run in window mode.
(5) GAPI DMA transfer on Casio devices. This should also correct the current issue with the E-125 and the EM-500 (thanks to Lucas Goodwin for reporting back!).
(6) (Idea from Sam Nova) New SetPixels function that uses arrays.
The new SetPixels will use arrays. It will also take an option to define element size.This would make it possible to define elements such as:

Code: Select all

1  2  3  4  5  6	typedef struct {     GDPIXEL pixel;     DWORD   dwXVel, dwYVel; } MYPIXEL; SetPixels((GDPIXEL*) pFirst, sizeof(MYPIXEL));
	6 lines; 3 keywds; 0 nums; 15 ops; 0 strs; 0 coms    Syntactic Coloring v0.4 - Dan East

Also, the pixel structure will be improved, allowing individual opacity for each pixel (allowing trails and similar particle effects). A new flag GDSETPIXEL_DISABLED will be added as well.

Code: Select all

1  2  3  4  5  6  7  8	typedef struct _GDPIXEL {     DWORD      dwX;       // X     DWORD      dwY;       // Y     COLORREF   dwColor;   // Color     DWORD      dwFlags;     GDPIXELFX* pGDPixelFx; } GDPIXEL;
	8 lines; 2 keywds; 0 nums; 9 ops; 0 strs; 3 coms    Syntactic Coloring v0.4 - Dan East

Changes:
(1) (With help from Andy Siegert) New alpha blend core. The speed of all alpha blends will be improved, allowing for real-time use in most game types. Watch out for a new performance demo!
(2) Improved video performance on Desktop PCs using DirectX DMA transfers.
(3) (Idea from Sam Nova) VerifyCoordinates will be renamed to SetSurfaceOptions. GetSurfaceOptions will be added as well. GDSURFOPTION_DONOTVERIFY and GDSURFOPTION_FIXEDPOINT will initially be supported to allow 16:16 fixed point coordinate support in all operations for the specific surface.
(4) Updated SetPixels() function.
The list version of SetPixels will now use a new struct format for the pixels, such as:

Code: Select all

1  2  3  4  5	typedef struct _GDPIXELNODE {     GDPIXEL       pixel;     _GDPIXELNODE* pNext; } GDPIXELNODE;
	5 lines; 2 keywds; 0 nums; 6 ops; 0 strs; 0 coms    Syntactic Coloring v0.4 - Dan East

(5) SetPixel - Flags and PixelFx will be added to the simple SetPixel function as well.

Under consideration:
(1) (Possible) Support for palettized devices. Direct screen writes will be disabled, and a quick color conversion could be done on the Flip(). The already slow performance of these devices would however be even slower since a bytewise copy&conversion would have to be done for each pixel, each frame. If surfaces were stored internally in 8-bit mode the copy could be done in larger chunks. But that would compromise on the performance for the other devices. So right now I don't know if it's worth the trouble. I will look into it.

[Hosed]

All the above features look awesome, especially the EM-500 issue

One thing I would like is a palettized surface, not necessarily palettized display support. Something I do in my game to reduce load times and mem usage is used palettized images with set palettes for specific layers. It also increases the speed conciderably. I then just perform the lookup and blit to the 16-bit surface once.

We can currently hack it with SetPixel and such, but native support in the API would be much welcomed.

Perhaps the PPCs are advancing at such a rate now though that this kind of feature isn't needed...

[Sam Nova]

Hi again,

Thanks for taking my ideas serious

I like you have the different resolutions and window alignment high on the list. The most improtant one for me would be to have the window in the correct resolution when you do a landscaped application (640x480 instead of 480x640), would make it SO much easier for debugging.

WOW.. Seems my idea for array setPixels will be implemented.

You write you plan to remove the old linked list setPixels, why ? I can still see many advantages of this one such as:
1. If you remove a pixel it will never take time. With the array you have to check the flags to see if it is active.
2. You don't have to allocate an array of worst case. Linked list can expanded as needed.
(Okay, you dont want to do too much allocation and deallocation runtime anyway).
But I will leave it to you to decide

The palletized device support could also be my fault To be honest, I'm not sure HOW important this is. I do know one game developer who released a shareware game that DID NOT support this. He has one customer who just bought the game without testing it.. this customer of course had a HP 525 so his game just crashed

If you don't plan to support these devices then please let the OpenDisplay return a error saying PALETTE_DEVICES_NOT_SUPPORTED

[Dan East]

That makes me think of another possible addition. This would pertain to any graphical library for Pocket PC. It would be useful to create a tiny app to test whether the toolkit supports the device's hardware. The app would only need to be 10-15k, and could be offered on the download pages of any apps using the toolkit.

Dan East

[Johan]

Great ideas, again.. I have updated the list above...

Dan: Good thinking.. I'll see what I can put together...

By the way. I was thinking of renaming the DLL to gapidraw11.dll to avoid versioning conflicts. I hope it won't impose any problems for anyone, please let me know if otherwise.

/Johan

[Sam Nova]

First of all to Dan East... First I didn't get what you where talking about now I do... not a bad idea at all... Except we need one for all CPUs...

I still have one open question to Johan, what DirectX version is needed ? will the PC versions of GapiDraw work on lets say NT3 ? with Direct X 3.0

About adding version number to the DLL files.. then PLEASE PLEASE...
I once had a problem with gapi.dll I think I had a game that used 1.0 or 1.1 and that game (from Jimmy Software I think) installed gapi.dll in the windows directory (I'm NOT a fan of this). So my own code stopped working the structure with the display information was all wrong So please use version number on the DLL's

[Johan]

Hi Sam,

GapiDrawXP uses the LPDIRECTDRAW7 interface, which means no NT3 support.

/Johan