BBC BASIC for Windows
General >> General Board >> Physical screen memory http://bb4w.conforums.com/index.cgi?board=general&action=display&num=1446124614 Physical screen memory
Post by Ric on Oct 29th, 2015, 1:16pm
Although new to bb4w (can't believe it has taken me this long to find it!) I was programming the BBC Micro back in the day with quite reasonable results even though I never went near assembly, to produce coloured graphics at sensible speed it was possible to poke directly the PSM with the simple command ?&xxxx=col% (albeit c% needed encoding depending on mode). Is this possible in bb4w and if not is there a faster method than PLOT 69? This will help me relive my youth and possibly much more.
Re: Physical screen memory
Post by DDRM on Oct 30th, 2015, 11:55am
Hi Ric,
It's not quite as simple as that, because the computer doesn't have "screen memory" in quite the same way. BB4W has an "output bitmap" which then gets written to the screen behind the scenes. You can't normally write directly to this bitmap, but it is possible to replace it with a "DIBSection", which you CAN write to directly. Have a look at this article:
D
Re: Physical screen memory
Post by Ric on Oct 30th, 2015, 6:37pm
Thanks DDRM, I'll give it a whirl. How difficult can it be!
Re: Physical screen memory
Post by Ric on Oct 31st, 2015, 9:19pm
DDRM (or anyone else that can help), I have now looked at a couple of options. It seems that bb4w is far advanced from the BASIC I used back in the early 80s in some ways, ie *DISPLAY. Using OSCLI this command works easily quick enough for my requirements with one problem I need to be able to move the object over a background and leave it intact. Is there a simple solution to this?
Re: Physical screen memory
Post by DDRM on Nov 1st, 2015, 7:05pm
Hi Ric,
OK, that's a whole different can of worms!
It sounds like what you are doing is some animation - with one picture moving over a different background image?
The obvious way is to use SPRITELIB. This normally requires .ICO files, but there is also a function to create a sprite from a bitmap, though the bitmap needs to include mask data - see the manual. It's possible, if your sprite image doesn't require transparency, that this will be easy to generate. There has been some discussion of routines to take a simple bitmap and render one colour (usually black) transparent, but I don't remember where we are with it - you could try searching this forum.
If you are *drawing* (ie using the BB4W drawing commands), you could use XOR plotting, which might suit what you are doing - try setting the plot mode with GCOL - ie. GCOL 3,15. You will find that if you draw something, then draw it again, it will be "undrawn" - but it has funny colour effects. It's POSSIBLE that this will affect displayed images - I may get a chance to try it sometime - but I'd be surprised.
If you can't use spritelib, and XOR plotting isn't suitable, you might find that simply re-DISPLAYing the background image, then re-displaying the "sprite" image in a new place, will be fast enough.
If you do "*REFRESH OFF" while you do any redrawing, the screen won't show intermediates or flicker: just do *REFRESH when you have finished drawing things (or *REFRESH ON)
You might also consider whether RECTANGLE TO might be helpful, though you'd have to work out a way of holding the bit under the sprite in the meantime. It's possible to have a screen bitmap bigger than the screen, so you can hide bits offscreen, but it's a bit fiddly...
If you want to get fiddly, you could consider setting up a "spare" device context and bitmap, and keeping a copy of your background in that. Then you could use the Windows Bitblt commands to replace the bit previously hidden by the "sprite"....
If that doesn't provide you with a solution, post a more specific example of what you are trying to do, and I'll have another think.
Best wishes,
D
Re: Physical screen memory
Post by Ric on Nov 2nd, 2015, 09:34am
Once again, thanks to DDRM. I have tried quite a few things over the last two weeks and have come to the conclusion that I will have to generate my own sprites an create a transparent black bit so not to disrupt the background and then reprint the background when the object has passed over the background. I have been on a steep learning curve over the past few days and have now mastered the equivalent of ?xxxx=col% PSM access using DIBSection, (many thanks for pointing me in the right direction). Combine that with the fiddly reading of the screen and plot again after the foreground sprite has moved, BINGO. Works a treat, yes I am trying to create arcade style graphics. Thought I may need to XOR the colours to achieve this but bb4w is fast enough to replot the background, combined with SYS"invalidaterect" and *REFRESH. The only down side is it requires 3D arrays and consequently memory! Time to upgrade Re: Physical screen memory
Post by David Williams on Nov 3rd, 2015, 04:16am
A couple of years ago I developed a library of sprite/bitmap plotting routines called GFXLIB.
If you get to grips with creating sprites, then using spritlib will make the rest easy: it keeps track of which layers are in front of which, it deals with redrawing the background, etc. - that sounds like the best solution to your problem - but it means generating sprites in the right format (which isn't that hard, and is almost certainly easier than "rolling your own" solution).
If David Williams is offering you use of his GFXLib, that might also be an excellent solution: as I recall, it has quite sophisticated routines to generate sprites from bitmaps. It also has quite a lot of fast plotting routines, which might be useful to you, if he is also offering that.
David, are you interested in makeing GFXLib more widely available again?
Best wishes,
D
Re: Physical screen memory
Post by ady on Nov 3rd, 2015, 09:23am
David, are you interested in makeing GFXLib more widely available again?
You may be better off starting a dedicated thread or sending a pm, he may not be reading individual threads
Re: Physical screen memory
Post by David Williams on Nov 3rd, 2015, 10:12am
David, are you interested in makeing GFXLib more widely available again?
I could put it up on my www.proggies.uk website (while it's still alive!).
Ric (and possibly others) would have to be aware of the following points:
- GFXLIB renders only 32bpp sprites - Its image loading function can load BMP, GIF and JPEG images (which get automatically converted to 32bpp raw bitmaps) - GFXLIB doesn't support custom graphics windows - It doesn't recognise BB4W's graphics window - Graphics windows can be simulated, somewhat inefficiently - Most programs and games which use GFXLIB redraw the entire window each and every frame (different to how SPRITELIB works) - The documentation is minimal, but has lots of examples - GFXLIB2 is big and bloated (but no DLL involved) - GFXLIB3 is compact and DLL-based (routines are coded in C, but still very fast), but as yet no documentation.
I'll wait and see what Ric wants to do. As previously mentioned, SPRITELIB may suffice for his needs.
David. --
Re: Physical screen memory
Post by ady on Nov 4th, 2015, 09:23am
I could put it up on my www.proggies.uk website (while it's still alive!).
Can I also suggest here that if anyone wants to keep work etc available "forever" to the wider community as a download then the pirate bay is a good repository for legal downloads (We all know about the not-legal bits) Sites come and go on the net and unfortunately the not so legal places have become far more reliable and permanent for disseminating useful stuff than 90% of the legal sites
(I use the place for downloading and uploading out-of-copyright engineering literature for instance)
Re: Physical screen memory
Post by Ric on Nov 4th, 2015, 5:48pm
Cheers for the advice guys, the sprites I have generated are true colour about 96 X 192 pixels. They work fine but with any additional code for baddies etc it will be too slow. I am trying to expand my languages skills as part of a personal challenge, this I am trying to succeed without external routines, (I may have to concede, but not yet). Is there a download for the assembly language, the equivalent of the "advanced user guide". After writing my routines in BBC Micro assembly I was quite disappointed to get a syntax error for LDX #0. Ho hum.
Re: Physical screen memory
Post by DDRM on Nov 5th, 2015, 08:28am
Hi Ric,
You are on a loser trying to write in BBC assembler (intended for a 6502 processor) for a Windows-based machine... As it says in the help files, BB4W includes an 80386/8046 assembler, with some extensions supported. There are a few differences from standard Intel syntax, which are noted in the help (look for the section on the assembler).
It's not something I'm familiar with, so I can't post a link, but you should be able to find online resources for such an assembler - I know I've found them in the past. Some of the whizzier members might be able to suggest something specific. Alternatively, if you email Richard Russell directly, he might well have some suggestions.
As an alternative, have you considered using the SYS interface to use Windows commands directly? It's quite straightforward to set up a device context and associated bitmap, load pictures into it, and then use BitBlt and associated commands to copy them to the output window - that's usually blindingly fast - almost certainly much faster than anything you'll cook up on your own (though David Williams might disagree!). I'll have a go at some sample code when I get a chance, but I'm absolutely run off my feet at the moment.
Best wishes,
D
Re: Physical screen memory
Post by Ric on Nov 5th, 2015, 09:06am
Thanks, I'll look for the right assembly language. Will contact RTR for help also. Keep you posted
Ric
Re: Physical screen memory
Post by ady on Nov 5th, 2015, 09:32am
Its basically intel x86 32 bit assembler
There's a visual aid called ketman which I used and simtel still has it. http://ftp.sunet.se/pub/simtelnet/msdos/asmutl/asmket15.zip 16 bit so ignore memory issues and interrupts, focus on what the wee widgets do in the processor, gives the clueless a decent grounding
Your asm code needs to be separated in BB4W into fixed data and code sections or performance is seriously crippled by cache re-writes as the fixed data changes
220 DIM code 2000 230 FOR opt=0 TO 2 STEP 2 240 P%=code 250 [OPT opt 260 .stor ;REM FIXED VARIABLES 270 mov dword [stor],0
450 ] 460 NEXT
480 FOR opt=0 TO 2 STEP 2 490 P%=code 500 P% = (P% + 6143) AND -6144 REM increments in 2048 blocks, so 3 blocks here 510 [OPT opt 520 530 REM MAIN CODE 540 .count 550 mov dword [stak],esp 4240 mov esp,[stak] 4250 ret 4260 4270 ] 4280 NEXT
A truly fascinating subject is asm but standard dudes like myself just won't live long enough to get good at it
Re: Physical screen memory
Post by ady on Nov 5th, 2015, 09:47am
You can also chat to windows with BBC asm, it's amazingly flexible
50 LOMEM = LOMEM+20000 60 REMHIMEM = LOMEM+20000000 70 REMHIMEM = HIMEM-40 80 90 DIM FF$(5) 100 FF$(0)="hello" FF$(1)="world" 110 120 REM REM REM SEE CRITICAL POINTER!!!!! 130 REM *FLOAT 64 290 300 REM SYS "SetWindowPos", @hwnd%, 0, 152, 17, 0, 0, 5
REMSYS "GetDeviceCaps", @prthdc%, 88 TO 150 REMSYS "GetDeviceCaps", @prthdc%, 90 TO 150
310 320 330 DIM code% 4000 340 FOR opt=0 TO 2 STEP 2 350 P%=code% 360 [OPT opt .count mov dword [count],0 .word1 mov eax,^FF$(0) mov dword [word1],eax ret
4990 5000 ] 5010 NEXT 5020 CALL count 5030 CALL stor 5580 REMPRINT USR(stor)
5620 PRINT "Finished" 5630 END
Good luck in figuring it all out Re: Physical screen memory
Post by KenDown on Dec 7th, 2015, 6:56pm
Don't forget that the simplest way to produce .ico files or .bmp files for conversion into sprites, is to download The Gimp (a free download) and use its graphics facilities.
Of course if you have a copy of Photoshop lying around you won't want The Gimp, but if you baulk at the cost of Photoshop, The Gimp is more than adequate.
