Author |
Topic: GFXLIB (Read 2316 times) |
|
David Williams
Developer
member is offline
meh
Gender: 
Posts: 452
|
 |
Re: GFXLIB
« Reply #93 on: Jan 9th, 2010, 8:38pm » |
|
Another day, another GFXLIB routine.
This one's called PlotRearrangeInvertRGB.
(Yikes !)
It rearranges the RGB colour components of every non-black pixel in a given bitmap, and then inverts the specified RGB components, then plots the pixel.
Code:SYS GFXLIB_PlotRearrangeInvertRGB%, dispVars{}, bmAddr, bmW, bmH, x, y, rgbRearrangementCode, rgbInversionFlags
The RGB rearrangement parameter is an integer in the range 0 to 5:
0. RGB (no rearrangement)
1. RBG
2. GRB
3. GBR
4. BRG
5. BGR
The RGB inversion flags parameter:
bit 0 ---> invert Red value
bit 1 ---> invert Green value
bit 2 ---> invert Blue value
So supplying a value of 1 for the inversion flags parameter will result in the red channel being inverted, 6 would result in both green and blue channels being inverted, etc.
Here's a demo of the routine (the above colour-transforming operation is applied in real-time in this program):
http://www.bb4w-games.com/bb4wprogs/plotrearrangeinvertrgb_demo.zip
Below is the original, unadulterated 64x64 ball bitmap (from the demo):
I may soon post a question in the Assembly Language section on what is the fastest possible way of rearranging and/or inverting RGB components of a pixel, because I'm probably doing it in one of the slowest ways.
Regards,
David.
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #95 on: Feb 6th, 2010, 10:01am » |
|
Thought I'd post this as it looks quite pretty (and uses not much CPU bandwidth):
http://www.bb4w-games.com/bb4wprogs/plotpixellist3_ex4.zip
Yes, OK, the Bézier curves are precalculated, but only because if they had to be calcluated in real time (in BASIC), the CPU usage would shoot right up (to ~50% on my laptop). The actual plotting of the curves takes next-to-no time.
What's supposed to be being demonstrated here is a new (but not terribly exciting) GFXLIB routine PlotPixelList3, which is faster and more flexible than the first two.
Interested folks might like to keep an eye on this page over the coming weeks:
http://www.bb4w-games.com/gfxlib2/gfxlib2page.html
Regards,
David.
|
|
|
|
81RED
Guest
|
|
Re: GFXLIB
« Reply #96 on: Feb 6th, 2010, 10:34am » |
|
on Feb 6th, 2010, 10:01am, David Williams wrote:
Yay!
Any benefits to be gained from recoding my stuff to use the new version (other than smaller code, which does not bother me), or is that better left off until my next project actually happens?
Simon
P.S. Weren't you supposed to be in rehab? 
|
|
 Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #97 on: Feb 6th, 2010, 11:29am » |
|
on Feb 6th, 2010, 10:34am, Simon Mathiassen wrote:Yay!
Any benefits to be gained from recoding my stuff to use the new version (other than smaller code, which does not bother me), or is that better left off until my next project actually happens?
|
|
Not really. The routines may have been 'modularized', but they haven't (yet) been optimized or improved in any other way.
A multicore version of the 'workhorse' routine BPlot - the one you'd normally use to draw backgrounds - may be in the pipeline. Whilst I doubt that four cores would necessarily translate to "four times faster" (which would be nice), BPlot (and Plot, as it happens) are such frequently used routines that it may be worthwhile trying to produce multicore/multithreading versions of them. The skills of Michael Hutton and/or Richard may (or rather, will) be indispensable here.
(Not that I would ever take either of them for granted, let me just say.)
on Feb 6th, 2010, 10:34am, Simon Mathiassen wrote:| P.S. Weren't you supposed to be in rehab? |
|
I evidently appear to be slipping.
Regards,
David.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #98 on: Feb 11th, 2010, 9:49pm » |
|
Here is a simple demo of a new routine called DrawTileMap:
(Use the arrow keys to move around)
http://www.bb4w-games.com/bb4wprogs/tilemapdemo1.zip
Using DrawTileMap is simplicity itself. First you need a set of tile bitmaps (all of the same dimensions - 64x64 is quite typical). Then you create a tile map using a map editor (a simple one will ship with GFXLIB 2). Then once you've installed and initialised GFXLIB 2, DrawTileMap and TileMapFunctions, and loaded the tile map with PROCLoadTileMap, you draw the portion of the map you wish to display using:
Code:SYS GFXLIB_DrawTileMap%, dispVars{}, mapInfo{}, x%, y%
Simple as that.
Something to look forward to, right?
Regards,
David.
PS. There will be a number of routines for converting between screen and map world coordinates, and routines intended for the purposes of collision detection. In fact, the following routines are already in place (with lots more to come):
Code:GFXLIB_TMConvertScrCoordsToWorldCoords% | *mapInfoStruc{}, scrX%, scrY%, *worldX%, *worldY%
GFXLIB_TMConvertWorldCoordsToScrCoords% | *mapInfoStruc{}, worldX%, worldY%, *scrX%, *scrY%
GFXLIB_TMConvertScrCoordsToWorldCoordsF64% | *mapInfoStruc{}, *scrX#, *scrY#, *worldX%, *worldY%
GFXLIB_TMConvertWorldCoordsToScrCoordsF64% | *mapInfoStruc{}, *worldX#, *worldY#, *scrX%, *scrY%
GFXLIB_TMGetTileIndexAtWorldPos% | *mapInfoStruc{}, worldX%, worldY% (returns tile index in EAX)
GFXLIB_TMGetTileIndexAtScrPos% | *mapInfoStruc{}, scrX%, scrY% (returns tile index in EAX)
GFXLIB_TMGetPixelAtWorldPos% | *mapInfoStruc{}, worldX%, worldY% (returns 32-bit ARGB pixel in EAX)
GFXLIB_TMGetPixelAlphaValueAtWorldPos% | *mapInfoStruc{}, worldX%, worldY% (returns 8-bit alpha value in EAX)
GFXLIB_TMTestPixelAlphaBitAtWorldPos% | *mapInfoStruc{}, worldX%, worldY%, testBit% (returns 0 or 1 in EAX)
|
|
|
|
Michael Hutton
Developer
member is offline
Gender:
Posts: 248
|
|
Re: GFXLIB
« Reply #99 on: Feb 12th, 2010, 02:12am » |
|
Very nifty piece of work!
My question is: What do the * mean in
*mapInfoStruc{}, *worldX#, *worldY#, *scrX%, *scrY%
I presume they are not C++ pointers?! Or is this a new type of BB4W addressing mode I haven't come accross?
Michael
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #100 on: Feb 12th, 2010, 02:49am » |
|
on Feb 12th, 2010, 02:12am, Michael Hutton wrote:My question is: What do the * mean in
*mapInfoStruc{}, *worldX#, *worldY#, *scrX%, *scrY%
I presume they are not C++ pointers?! Or is this a new type of BB4W addressing mode I haven't come accross?
|
|
Actually, I don't think it was correct of me to prefix mapInfoStruc{} with an asterisk.
Yes, an asterisk indicates that the parameter is a pointer to a memory location that contains (or is to contain) either an integer or a 64-bit float.
I realise that 32-bit floats can be supplied 'directly' using FN_f4, but it's probably not suitable for heavy use within a game loop.
By the way, those comments are really just notes to myself. I don't normally use asterisks to indicate pointer variables! I might from now on, though.
Regards,
David.
|
|
Logged
|
|
|
|
Richard Russell
Guest
|
|
Re: GFXLIB
« Reply #101 on: Feb 12th, 2010, 08:11am » |
|
on Feb 12th, 2010, 02:49am, David Williams wrote:| I don't normally use asterisks to indicate pointer variables! I might from now on, though. |
|
Is there a particular reason why you don't use ^, to reflect the syntax you'd use if calling the routine from BASIC?
Richard.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #102 on: Feb 12th, 2010, 3:05pm » |
|
on Feb 12th, 2010, 08:11am, Guest-Richard Russell wrote:Is there a particular reason why you don't use ^, to reflect the syntax you'd use if calling the routine from BASIC?
|
|
Perhaps I suffered a momentary lapse of common sense.
David.
|
|
Logged
|
|
|
|
81RED
Guest
|
|
Re: GFXLIB
« Reply #103 on: Feb 14th, 2010, 7:19pm » |
|
on Feb 11th, 2010, 9:49pm, David Williams wrote: Code:SYS GFXLIB_DrawTileMap%, dispVars{}, mapInfo{}, x%, y%
Simple as that.
Something to look forward to, right?
|
|
Bloody hell! That looks VERY useful indeed.
Am I correct in guessing your experiences coding Crystal Hunter II had something to do with it?
Simon
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #104 on: Feb 15th, 2010, 01:36am » |
|
on Feb 14th, 2010, 7:19pm, Simon Mathiassen wrote:Bloody hell! That looks VERY useful indeed.
Am I correct in guessing your experiences coding Crystal Hunter II had something to do with it?
Simon |
|
No, I don't think so.
In addition to those tile map-related routines, I've started work on a new library called GAMEOBJLIB (Game Object Library), although don't be too surprised if the final release version is called something else. It's aim (whether it'll be achieved or not) is to simplify and speed up the development of 2D games, especially ones with extended 'worlds' - such as scrolling platformers, shoot-'em-ups, etc. I'll probably have some demos of it in action soon.
Regards,
David.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #105 on: Jun 27th, 2010, 02:33am » |
|
I've uploaded GFXLIB version 2.00 to my website's FTP area, although I don't yet have a separate web page dedicated to it. That'll come in a few days.
Download link
http://www.bb4wgames.com/progs/zip/gfxlib2.zip [3.93 MB]
Quick Start Guide
http://www.bb4wgames.com/misc/GFXLIB2QuickStartGuide.pdf
There is plenty of documentation in the form of example programs (at least one example program and Info.TXT file for almost every GFXLIB routine).
Also included in the package are dozens of demo programs originally written for GFXLIB 1, but which have since been modified to work with GFXLIB 2. I apologise in advance for the fact that the program code for some of the demos is rather cryptic and poorly commented.
One of the most important differences between this version (2.00) and previous beta versions of GFXLIB 2 is that the name of the display variables structure (dispVars{}) must now be declared when initialising GFXLIB 2:
Code:
INSTALL @lib$ + "GFXLIB2"
PROCInitGFXLIB( dispVars{}, 0 )
Happy game writing ?
Regards,
David.
http://www.bb4wgames.com
|
|
Logged
|
|
|
|
81RED
Guest
|
|
Re: GFXLIB
« Reply #106 on: Jun 27th, 2010, 09:44am » |
|
Congratulations! Wow, that was a LONG and difficult birth – glad you got there in the end. 
EDIT: Has dibSectionaddr% simply been replaced by dibs%, or is there more to it than that?
|
| « Last Edit: Jun 27th, 2010, 10:37am by 81RED » |
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #107 on: Jun 27th, 2010, 1:26pm » |
|
on Jun 27th, 2010, 09:44am, Simon Mathiassen wrote:| Congratulations! Wow, that was a LONG and difficult birth – glad you got there in the end. |
|
Thanks. Things are still far from ideal, though.
on Jun 27th, 2010, 09:44am, Simon Mathiassen wrote:| EDIT: Has dibSectionaddr% simply been replaced by dibs%, or is there more to it than that? |
|
The global variable dibs% has simply replaced dibSectionAddr%, although they did exist concurrently for a while.
Perhaps the global variables declared upon initialising GFXLIB will disappear altogether in subsequent versions. Their fate depends on how much hassle this would cause the end-user (and myself!).
Regards,
David.
|
|
|
|
|
