BBC BASIC for Windows
« GFXLIB »

Welcome Guest. Please Login or Register.
Apr 6th, 2018, 12:15am



ATTENTION MEMBERS: Conforums will be closing it doors and discontinuing its service on April 15, 2018.
Ad-Free has been deactivated. Outstanding Ad-Free credits will be reimbursed to respective payment methods.

If you require a dump of the post on your message board, please come to the support board and request it.


Thank you Conforums members.

BBC BASIC for Windows Resources
Online BBC BASIC for Windows documentation
BBC BASIC for Windows Beginners' Tutorial
BBC BASIC Home Page
BBC BASIC on Rosetta Code
BBC BASIC discussion group
BBC BASIC for Windows Programmers' Reference

« Previous Topic | Next Topic »
Pages: 1 2 3 4  ...  9 Notify Send Topic Print
 veryhotthread  Author  Topic: GFXLIB  (Read 2235 times)
admin
Administrator
ImageImageImageImageImage


member is offline

Avatar




PM


Posts: 1145
xx Re: GFXLIB
« Reply #5 on: Aug 28th, 2008, 10:27pm »

Quote:
time is wasted in performing this CALL (since this flushes the pipeline, I believe)

Are you sure? I can't see any mention of that in the Intel Architecture Optimization Reference Manual. Inlining CALLs is recommended, but only for 'peripheral' reasons:

• Parameter passing overhead can be eliminated.
• In a compiler, inlining a function exposes more opportunity for optimization.
• If the inlined routine contains branches, the additional context of the caller may improve branch prediction within the routine.
• A mispredicted branch can lead to larger performance penalties inside a small function than if that function is inlined.

I doubt that any of these apply significantly in your case. In general the CPU is "optimized specifically for calls and returns" (e.g. the trace cache) so I don't think you need worry too much about the overhead.

Richard.
User IP Logged

David Williams
Developer

member is offline

Avatar

meh


PM

Gender: Male
Posts: 452
xx Re: GFXLIB (Fast Text Drawing)
« Reply #6 on: Aug 29th, 2008, 02:53am »

The next release of GFXLIB will feature some fast text drawing subroutines.

Here's a demo:

http://www.bb4w-games.com/fastfontdemo.zip

The screen redraw is supposed to be sync'd with the monitor's VBlank, but if the synchronisation is not good then please don't form the impression that the text drawing routine is slow!


Regards,

David.
« Last Edit: Jan 19th, 2012, 2:13pm by David Williams » User IP Logged

David Williams
Developer

member is offline

Avatar

meh


PM

Gender: Male
Posts: 452
xx Re: GFXLIB (demo of PlotDissolve3 routine)
« Reply #7 on: Aug 31st, 2008, 8:21pm »

The next public release of GFXLIB will include a new routine called PlotDissolve3.

Watch this demo to see what it does:

http://www.bb4w-games.com/plotdissolve3demo.zip

The routine is currently very suboptimal -- it calls Richard's pseudo-random number generator every d**ned pixel, so some kind of shortcut needs to be devised even if that means A) huge table of random numbers, or B) a faster but lower quality random number generator.

(Not suggesting Richard's routine is slow -- it isn't -- just that I'm happy to compromise high quality pseudo-randomness for speed in this case).


Regards,

David.
« Last Edit: Jan 19th, 2012, 2:14pm by David Williams » User IP Logged

admin
Administrator
ImageImageImageImageImage


member is offline

Avatar




PM


Posts: 1145
xx Re: GFXLIB
« Reply #8 on: Aug 31st, 2008, 8:46pm »

Quote:
Watch this demo to see what it does


You may not like David Tennant as Doctor Who, but at least you have the satisfaction of knowing that BBC BASIC for Windows may end up having a significant (retrospective) contribution to make to Jon Pertwee's depiction of the role! For more details see the September 2008 edition of Everyday Practical Electronics (page 16).

Richard.
User IP Logged

David Williams
Developer

member is offline

Avatar

meh


PM

Gender: Male
Posts: 452
xx Re: GFXLIB (full screen demo)
« Reply #9 on: Sep 4th, 2008, 12:38am »

A simple full screen demo:

http://www.bb4w-games.com/fullscreendemo.zip

I was surprised to get the 'ideal' (VBlank-sync'd) frame rate of 60 fps on my 1.86GHz Centrino-based laptop. However, the CPU load was rather high at approx. 50%. Also, the VBlank synchronisation isn't perfect, but it's better than no sync, IMO.

Regards,

David.


« Last Edit: Jan 19th, 2012, 2:14pm by David Williams » User IP Logged

David Williams
Developer

member is offline

Avatar

meh


PM

Gender: Male
Posts: 452
xx Re: GFXLIB (Fast bitmap scaling)
« Reply #10 on: Sep 4th, 2008, 09:12am »

Some very fast -- albeit low quality nearest-neighbour -- bitmap scaling:

http://www.bb4w-games.com/fastscalingdemo.zip
« Last Edit: Jan 19th, 2012, 2:14pm by David Williams » User IP Logged

admin
Administrator
ImageImageImageImageImage


member is offline

Avatar




PM


Posts: 1145
xx Re: GFXLIB
« Reply #11 on: Sep 4th, 2008, 2:36pm »

Quote:
Some very fast -- albeit low quality nearest-neighbour -- bitmap scaling


This appears to be broken on my PC: the 'GFXLIB' text, which I presume is intended to be in the foreground, is partially hidden most of the time:

User Image

Richard.
User IP Logged

David Williams
Developer

member is offline

Avatar

meh


PM

Gender: Male
Posts: 452
xx Re: GFXLIB
« Reply #12 on: Sep 4th, 2008, 4:51pm »

on Sep 4th, 2008, 2:36pm, Richard Russell wrote:
This appears to be broken on my PC: the 'GFXLIB' text, which I presume is intended to be in the foreground, is partially hidden most of the time:


Oops... yes, I had REM'd out the *REFRESH statement and forgot to un-REM it prior to compilation.

It should work o.k. now.

http://www.bb4w-games.com/fastscalingdemo.zip


David.
« Last Edit: Jan 19th, 2012, 2:15pm by David Williams » User IP Logged

David Williams
Developer

member is offline

Avatar

meh


PM

Gender: Male
Posts: 452
xx Re: GFXLIB (text squashing)
« Reply #13 on: Sep 5th, 2008, 12:05am »

This will be the last GFXLIB demo for a month or two because I really must get the documentation and example programs written...

http://www.bb4w-games.com/textsquash.zip


I intend to release the next version of GFXLIB (with lots of new routines plus decent docs) by the end of this month, or early October. I hope then that it'll not just be me and Simon writing games based on it smiley

Check out Simon's game 'Blast' which promises some frantic arcade action (you'll probably need to extract the files from the ZIP folder first before running it):

http://www.bb4w-games.com/blast.zip


Regards,

David.
« Last Edit: Jan 19th, 2012, 2:15pm by David Williams » User IP Logged

admin
Administrator
ImageImageImageImageImage


member is offline

Avatar




PM


Posts: 1145
xx Re: GFXLIB
« Reply #14 on: Sep 5th, 2008, 08:22am »

Quote:
Check out Simon's game 'Blast' which promises some frantic arcade action (you'll probably need to extract the files from the ZIP folder first before running it)

Do you happen to know why he doesn't package all the 'resource' files into the executable? Personally I can't be bothered to download the zip and find somewhere suitable to extract all the files.

Your programs are so much easier to run; I don't even have to download them (explicitly), I just 'open' the link in your post then double-click on the executable. Wonderful!
User IP Logged

David Williams
Developer

member is offline

Avatar

meh


PM

Gender: Male
Posts: 452
xx Re: GFXLIB (Scaled game graphics)
« Reply #15 on: Sep 8th, 2008, 12:47am »

I wanted to try an experiment with a view to perhaps creating a game that is largely independent of screen resolution. The method used in this demo (link below) involves the pre-scaling of bitmaps using simple nearest-neighbour scaling, and then these pre-scaled bitmaps are drawn in the usual way using the reasonably fast standard GFXLIB_Plot routine.

http://www.bb4w-games.com/scaledgamegraphicsdemo.zip

The demonstration 'game' doesn't do much -- use the arrow keys to move around and collect objects. Not much fun... but then, the point of the program is to demonstrate an idea/concept, not to entertain smiley

You have to re-start the program in order to change the resolution.


Regards,

David.
« Last Edit: Jan 19th, 2012, 2:15pm by David Williams » User IP Logged

81RED
Guest
xx Re: GFXLIB
« Reply #16 on: Sep 10th, 2008, 07:02am »

on Sep 5th, 2008, 08:22am, Richard Russell wrote:
Do you happen to know why he doesn't package all the 'resource' files into the executable? Personally I can't be bothered to download the zip and find somewhere suitable to extract all the files.

Your programs are so much easier to run; I don't even have to download them (explicitly), I just 'open' the link in your post then double-click on the executable. Wonderful!


To quote what I wrote to David on that subject:
"Can only speak from personal experience, but in my end of the world, users
Have a nasty tendency to download stuff directly to their desktop.
Now having a Blast.exe that "explodes" into 29 additional items on said desktop Is not the ideal way to make friends "
And I could go on and on about that particular subject, but I guess I'm as opposed to programs that uncritically and without warning clutters up the folder they happen to be run in, as you are to unzipping anything.

Simon
User IP Logged

admin
Administrator
ImageImageImageImageImage


member is offline

Avatar




PM


Posts: 1145
xx Re: GFXLIB
« Reply #17 on: Sep 10th, 2008, 09:14am »

Quote:
Now having a Blast.exe that "explodes" into 29 additional items on said desktop Is not the ideal way to make friends

I suggested that you "package the resource files into the executable", not that you 'explode' 29 items onto the desktop. One doesn't follow from the other!

For a start, I would always recommend putting the resource files into a single sub-directory, not keeping them in the same directory as the executable. Thus if one were to download the executable to the desktop and run it there the most that would happen is that a single additional folder icon would appear.

Arguably the appearance of that icon isn't in itself a bad thing, since it would draw attention to what is in any case bad practice - putting an executable file on the desktop. However it could easily be removed by setting the resource directory's attributes to 'hidden' early in your program.

But what I think is more important is that David's method of embedding all the resource files means that you don't have to (explicitly) download the programs at all. To run one of his programs I just 'open' it from the web site - the downloading and extraction of resource files to a temporary directory happens 'behind the scenes'. Literally his programs are four mouse-clicks away from a message on this forum.

Anyway it's ultimately up to you. I've marvelled at David's programs but I've not even looked at yours because I can't be bothered with the hassle of downloading, extracting and subsequently deleting it.

Richard.
User IP Logged

81RED
Guest
xx Re: GFXLIB
« Reply #18 on: Sep 10th, 2008, 10:37am »

Quote:
I suggested that you "package the resource files into the executable", not that you 'explode' 29 items onto the desktop. One doesn't follow from the other!

Admittedly, no. But, with the danger of repeating myself, there will always be a risk when you unpack something without the users consent or control.

Quote:
For a start, I would always recommend putting the resource files into a single sub-directory, not keeping them in the same directory as the executable. Thus if one were to download the executable to the desktop and run it there the most that would happen is that a single additional folder icon would appear.

The files in the Blast.zip contains *two* files in the root of the archive - a Blast.exe and a readme. The rest is in a \data folder.

Quote:
Arguably the appearance of that icon isn't in itself a bad thing, since it would draw attention to what is in any case bad practice - putting an executable file on the desktop. However it could easily be removed by setting the resource directory's attributes to 'hidden' early in your program.

Hang on a moment, did you just suggest that I clutter the users harddrive, only to hide it afterwards? I sincerely hope I read that paragraph wrong..

Quote:
But what I think is more important is that David's method of embedding all the resource files means that you don't have to (explicitly) download the programs at all. To run one of his programs I just 'open' it from the web site - the downloading and extraction of resource files to a temporary directory happens 'behind the scenes'. Literally his programs are four mouse-clicks away from a message on this forum.

May I suggest WinRAR. It makes running anything inside a zip file equally simple to what you describe above.
Be warned though - WinRAR requires that you actually install it.

Quote:
Anyway it's ultimately up to you. I've marvelled at David's programs but I've not even looked at yours because I can't be bothered with the hassle of downloading, extracting and subsequently deleting it.

Hmm.. I'm still glad I could "be bothered" to download a certain compiler, run the installer, click "next" an amount of times, enter a serial number, click "next" a few more times etc. so that I could produce Blast in the first place.

That you cannot "be bothered" to unzip my game is just something I will have to live with.

Simon
User IP Logged

admin
Administrator
ImageImageImageImageImage


member is offline

Avatar




PM


Posts: 1145
xx Re: GFXLIB
« Reply #19 on: Sep 10th, 2008, 2:42pm »

Quote:
The files in the Blast.zip contains *two* files in the root of the archive - a Blast.exe and a readme. The rest is in a \data folder.

So where do those 29 items on the desktop come from when you embed them? I would have expected there to be just two (in addition to the executable): a folder icon and a readme icon.

Quote:
Hang on a moment, did you just suggest that I clutter the users harddrive, only to hide it afterwards? I sincerely hope I read that paragraph wrong..

What's wrong with that? Loads of applications install 'hidden' files, and as for cluttering the user's hard drive you can simply delete the folder when your program exits. Another solution is to store your resource files in a subdirectory of @lib$, in which case they are deleted automatically on exit.

Quote:
I'm still glad I could "be bothered" to download a certain compiler, run the installer, click "next" an amount of times, enter a serial number, click "next" a few more times etc. so that I could produce Blast in the first place.

I don't see that it's a valid comparison. If you develop your game into a fully-fledged application that needs to be 'installed' then of course I'd have no objection to carrying out those steps. I'd still encourage you to use a proper installer (so that again I can just 'run' the program from a web page) rather than require me to download it and extract the files manually.

I'm puzzled at your negative reaction to what was intended to be a practical suggestion to improve the user-friendliness of your software. It's a strength of BBC BASIC for Windows that you can embed resource files in the executable, and being able just to 'run' a program from a website or forum message seems to me a useful feature, so long as it is used appropriately.

User IP Logged

Pages: 1 2 3 4  ...  9 Notify Send Topic Print
« Previous Topic | Next Topic »

| |

This forum powered for FREE by Conforums ©
Terms of Service | Privacy Policy | Conforums Support | Parental Controls