Posts: 268
Threads: 9
Joined: Dec 2004
Ok, fixed both things :wink:
FLIP support is now there for legacy with gfxlib; it does nothing but at least your sources using it compile.
Nek, I also modified the doc about CLS... the new version is also up there in the original post (I edited it to reflect the change).
The new zip holding both modifications has replaced the old one, so for those who care you need to redownload it from the same URL above.
Posts: 1,407
Threads: 117
Joined: Dec 2002
Angelo:
A suggestion:Implement fake POKEs to screen (only mode 13) and a lot of old demos would work in FB....
Since you have your hands in the stuff...
Antoni
Posts: 268
Threads: 9
Joined: Dec 2004
PEEK and POKE are already implemented by FB itself, and translate to direct memory accesses. I don't think it's a good idea to change them to emulate DOS behaviours (think segments and VGA access), it'd add overhead that would not be really worth it IMHO...
Posts: 1,407
Threads: 117
Joined: Dec 2002
You're right....
After all a POKE to screen can be translated by a macro into a PSET.... when macros are implemented.
Antoni
Posts: 3,279
Threads: 170
Joined: Nov 2003
Great lillo, that's way more understandable. Z!re, keep in mind that not everyone knows about that...some of us have our own methods which are not "standard".
I'd knock on wood, but my desk is particle board.
Posts: 1,272
Threads: 36
Joined: Feb 2003
I agree, not needing SDL.dll and not needing to FLIP are major, important improvements. I'm sure both were confusing a lot of people trying to migrate from QB.
You also dramatically cut down on the generated EXE size - cool.
I think it's pretty clear that yours shouldn't be the alternative one anymore.
Posts: 251
Threads: 22
Joined: Dec 2004
Quote:I think it's pretty clear that yours shouldn't be the alternative one anymore.
... on Windows.
But on Linux you still are in need of a graphic lib like sdl.
Maybe your work can be used as a starting point for the linux platform...
BTW: lillo's gfx lib is written in c, is there a reason why not do it in freebasic?
Just a question... not critisism
IMHO it would be nice if everything that comes from the freebasic community would be written in freebasic.
This would strengthen freebasic a lot. 8)
Posts: 1,439
Threads: 15
Joined: Apr 2003
If everything were written in fb, it'd be a headache to compile it all (for the first time at least) on other platforms if the pieces are required by FB. I guess the gfxlib isn't really required to build the compiler, but I dunno... C compilers have some pretty 1337 optimizations that fb doesn't have (yet... :x )
Posts: 268
Threads: 9
Joined: Dec 2004
fsw, my gfxlib uses a tiny drivers architecture internally, and it's easy to add new gfx drivers. The DirectDraw driver is itself just a single .c file of 12K, compiles to 10K of object code and holds *all* the Win32 specific stuff needed by the lib to work. A similar driver for X11 using XLib is planned, and it'll not be hard to code. So no need for SDL under Linux as well.
Posts: 73
Threads: 6
Joined: Jan 2005
how to use PAINT with this lib? I get
Quote:test.bas(9) : error 9: Expected expression, found: ')'
<--- when I use PAINT (16, 16), 12, 11
test.bas(9) : error 9: Expected expression <--- when I use PAINT 16, 16, 12, 11
Code: declare sub draw alias "fb_GfxDraw" (byref cmd as string)
declare sub paint alias "fb_GfxPaint" (byval x as single, byval y as single, _
byval color as integer = &hFFFF0000, byval border as integer = &hFFFF0000, _
byref pattern as string, byval mode as integer = 0, _
byval coord_type as integer = 4)
SCREEN 12
LINE (5, 5)-(200, 200), 11, B
PAINT (16, 16), 12, 11 <--ok in QB, but error 9 in fbc
'PAINT 16, 16, 12, 11 <--I have also tested this one, error 9 too
I just test this lib, so please forget the BoxFill in line statement.
|
