Alternative GFXlib released

[lillo]

ok, new version released, same location:

http://www.ecplusplus.com/index.php?page...fxlib2.zip

Changes:

* PALETTE now supports EGA emulation
* MMX optimized PUT routines (PSET, PRESET, AND, OR, XOR and TRANS)
* CIRCLE start/end arc parameters not limited to 0-2PI anymore: negative values behave like in QB (plot lines)
* Added safe guards to functions so your app doesn't crash if you use gfx statements while not in gfx mode
* Fixed FLIP compatibility
* Fixed a bug with relative coordinates via STEP

steven_basic, with this version your brix works like a charm 8)
Just had to change CHR$(0) to CHR$(255)...

retsyo: I'm still investigating for the problem with your program... But let me first say that whoever coded that stuff is a fool and should be interned! Anyway... the problem is not with PAINT, but with CIRCLE: the app uses a lot of arcs, and the ellipse algorithm I used for CIRCLE obviously differs from the one used by QB, so it's not equal to it pixel-by-pixel. As your app requires pixel precision due to the many PAINTs used, that causes problems.
I'll see if I can make my CIRCLE more similar to the QB one...

[Sterling Christensen]

Simply exchanging his lib now wouldn't be too fair with him

It's ok, really.

i really don't know what to do.. well, you guys are both members, you can get along, don't leave it to me to decide .

Alright, I've already told Angelo that I think it would be better for FB to include his instead - so it's decided.

[adosorken]

SC, why not work yours into a seperate library? It would make more sense anyways, especially for people who want the highcolor/hires modes.

[na_th_an]

na_th_an: thanks. About your question, I could export to the user this set of functions which could suit your needs:

Code:

SCREENLOCK

This would lock the framebuffer. No updates are done to the screen while the lock is held.

Code:

SCREENPTR

Function that returns a pointer to the video memory (actually this is just an internal memory buffer the gfxlib uses). You can safely read/write to this memory as long as you have previously called SCREENLOCK.

Code:

SCREENUNLOCK

Unlocks the screen which was previously locked via SCREENLOCK. When you call this function, the screen gets instantly updated again automatically. You cannot touch again the memory buffer returned via SCREENPTR as long as you don't recall SCREENLOCK first.

That would be awesome. You know, without methods like those coding flicker-free games would be difficult, unless the emulated WAIT &H3DA,8 and WAIT &H3DA,8,8 provide a method to know when the screen is gonna be repainted.

Definitely, I'll use this thingo to port Jill once the functions are exported.

Code:

About PUTing to other buffers, well, I think this is a bit out of the scope of a default FB GFX library... You could still use your own memory buffers, code your blitters and then blit to your buffers, then use the SCREENLOCK/UNLOCK/PTR interface above to blit your buffer to the screen.

Sure, I just thought that it would be easy enough to achieve. I'll take a peek at the sources

[steven_basic]

ok, new version released, same location:

Very nice.

I find it amazing how well everyone is working together on freeBASIC. The raw speed at which it is evolving just staggers the mind.

...or at least it does mine...

[SJ Zero]

Should open source developers be looking at that?

[na_th_an]

It's just an algo. Nobody would care. I posted it for reference, so lillo can figure out which algo they followed. I'm pretty sure they didn't invent it (MS isn't known for inventing things, you can bet ).

[v3cz0r]

Please, don't put it online on this forum, i know m$ gives a rat ass to fb, but that's copyrighted code, from leaked source, we can't use it.

I will pretend i didn't see it ;)

Thanks..

[barok]

One request... could you make a command that could create a custom screen size, like in sterling's fbgfx?

[Jotz]

Is there a way to make it start in fullscreen mode?