Author |
Topic: GFXLIB (Read 2203 times) |
|
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.
|
|
|
|
admin
Administrator
member is offline


Posts: 1145
|
 |
Re: GFXLIB
« Reply #108 on: Jun 27th, 2010, 5:57pm » |
|
on Jun 27th, 2010, 1:26pm, David Williams wrote:| Perhaps the global variables declared upon initialising GFXLIB will disappear altogether in subsequent versions. |
|
Am I right in thinking that none of these 'global variables' are actually needed by the user's program, but are provided only as an 'optional extra' to save him some effort (for example the predefined bitmap bm32%)? I understood that all the 'essential' shared variables are stored in dispVars{} and therefore not actually 'global'.
Richard.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline

meh

Gender: 
Posts: 452
|
 |
Re: GFXLIB
« Reply #109 on: Jun 27th, 2010, 7:00pm » |
|
on Jun 27th, 2010, 5:57pm, Richard Russell wrote:Am I right in thinking that none of these 'global variables' are actually needed by the user's program, but are provided only as an 'optional extra' to save him some effort (for example the predefined bitmap bm32%)? I understood that all the 'essential' shared variables are stored in dispVars{} and therefore not actually 'global'. |
|
A number of basic 'core' routines are assembled in GFXLIB2.BBC, including Plot, BPlot, and Clr. The addresses of these 'workhorse' routines are stored in global variables (GFXLIB_Plot%, GFXLIB_BPlot%, GFXLIB_Clr%, etc.). Which is why a user of GFXLIB 2 can simply do this to get a bitmap plotted:
Code:REM. Display a pre-defined 64x64 bitmap
MODE 8
INSTALL @lib$ + "GFXLIB2"
PROCInitGFXLIB( dispVars{}, 0 )
SYS GFXLIB_Plot%, dispVars{}, bm32%, 64, 64, 320, 256
PROCdisplay
(Yes, PROCdisplay is defined in GFXLIB2.BBC).
A few other global variables are created in GFXLIB2.BBC as well, including those containing the address of some trigonometric and division tables required by some of the external GFXLIB modules.
For every external GFXLIB module that the user INSTALLs, another global variable is created. For example, the external module PlotBlend creates a new global called GFXLIB_PlotBlend%:
Code:
MODE 8
INSTALL @lib$ + "GFXLIB2" : PROCInitGFXLIB( dispVars{}, 0 )
INSTALL @lib$ + "GFXLIB_modules\PlotBlend.BBC" : PROCInitModule
SYS GFXLIB_PlotBlend%, dispVars{}, bm32%, 64, 64, 320, 256, 80
PROCdisplay
I was going to have the user initialise the module using something like (for example):
Code:INSTALL @lib$ + "GFXLIB_modules\PlotBlend.BBC"
plotblend% = FNInitModule
Which would at least have the global created within the user's program, rather than in the module.
But I'd completely forgotten about implementing this idea until about er... 15 seconds ago.
Not to mention the considerable extra work that would be involved.
Regards,
David.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline


Posts: 1145
|
 |
Re: GFXLIB
« Reply #110 on: Jun 27th, 2010, 9:51pm » |
|
on Jun 27th, 2010, 7:00pm, David Williams wrote:| The addresses of these 'workhorse' routines are stored in global variables (GFXLIB_Plot%, GFXLIB_BPlot%, GFXLIB_Clr%, etc.) |
|
OK. I suppose I wasn't counting the actual routine addresses as global variables, but I see what you mean.
Quote:I was going to have the user initialise the module using something like (for example)... plotblend% = FNInitModule |
|
Yes, that seems a nice way to do it and decouples the library's name space from the user's name space.
Richard.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline

meh

Gender: 
Posts: 452
|
 |
Re: GFXLIB
« Reply #111 on: Jul 2nd, 2010, 01:51am » |
|
"Flying pink worm" demo (DirectX9 fullscreen version)
Nothing new here really, just a previously uploaded GFXLIB demo modified to employ Michael Hutton's GFXD3D9LIB for fullscreen DirectX9 display.
DirectX9 is therefore required. Users running the demo on older computers (more than 8 years old, let's say) should expect a low frame rate.
http://www.bezu.co.uk/filesdump/temp/progs/flyingpinkworm-dx9.zip
Press SPACE BAR during the demo to exit. Don't press Alt+F4 to exit.
The forthcoming release of GFXLIB (version 2.01) will, apart from some important modifications, contain a few additional programs demonstrating the use of GFXD3D9LIB.
David.
|
|
|
|
admin
Administrator
member is offline


Posts: 1145
|
 |
Re: GFXLIB
« Reply #112 on: Jul 3rd, 2010, 9:06pm » |
|
on Jul 2nd, 2010, 01:51am, David Williams wrote:| Don't press Alt+F4 to exit. |
|
Why not? It's what I always do to exit a full-screen program (if there's no obvious alternative). Tony Tooth's full-screen programs specifically tell you to quit them that way.
If for some reason you really don't want Alt-F4 used, put an ON CLOSE RETURN in the program, but in that case I'd expect pressing Esc to work.
Richard.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline

meh

Gender: 
Posts: 452
|
 |
Re: GFXLIB
« Reply #113 on: Jul 3rd, 2010, 11:30pm » |
|
on Jul 3rd, 2010, 9:06pm, Richard Russell wrote:
Circuitous answer: Why would you want to press Alt+F4 (two keystrokes) to exit the program when you can simply press Space Bar?
Alt+F4 is more fiddly and more energy consuming.
The other reason is that this particular version of the program might not exit cleanly if you press Alt+F4.
David.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline


Posts: 1145
|
 |
Re: GFXLIB
« Reply #114 on: Jul 4th, 2010, 09:54am » |
|
on Jul 3rd, 2010, 11:30pm, David Williams wrote:| Why would you want to press Alt+F4 (two keystrokes) to exit the program when you can simply press Space Bar? |
|
Because by that time I've forgotten that it said to press the Space Bar (if I ever noticed in the first place!).
Because Alt+F4 is a standard way of quitting a program (there's a standard for a single-key exit too, but it's Esc not Space).
Quote:| The other reason is that this particular version of the program might not exit cleanly if you press Alt+F4 |
|
I'm surprised. Normally Windows does a good job of cleaning up after itself when quitting an executable (of course Alt+F4 might not work when running the program in the IDE, but I don't have the opportunity to do that!). But, as I said, in that case you should include ON CLOSE RETURN in your code, not rely on the user reading the instructions!
Richard.
|
| « Last Edit: Jul 4th, 2010, 09:57am by admin » |
Logged
|
|
|
|
|