Author |
Topic: Physical screen memory (Read 1612 times) |
|
Ric
Full Member
member is offline
Gender: 
Posts: 136
|
 |
Physical screen memory
« Thread started 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.
|
|
 Logged
|
It's always possible, but not necessarily how you first thought. Chin up and try again.
|
|
|
DDRM
Administrator
member is offline
Gender:
Posts: 321
|
|
Re: Physical screen memory
« Reply #1 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:
http://bb4w.wikispaces.com/Direct+screen+memory+access
Best wishes,
D
|
|
Logged
|
|
|
|
Ric
Full Member
member is offline
Gender:
Posts: 136
|
|
Re: Physical screen memory
« Reply #2 on: Oct 30th, 2015, 6:37pm » |
|
Thanks DDRM, I'll give it a whirl. How difficult can it be!
|
|
Logged
|
It's always possible, but not necessarily how you first thought. Chin up and try again.
|
|
|
Ric
Full Member
member is offline
Gender:
Posts: 136
|
|
Re: Physical screen memory
« Reply #3 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?
|
|
Logged
|
It's always possible, but not necessarily how you first thought. Chin up and try again.
|
|
|
DDRM
Administrator
member is offline
Gender:
Posts: 321
|
|
Re: Physical screen memory
« Reply #4 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
|
|
Logged
|
|
|
|
Ric
Full Member
member is offline
Gender:
Posts: 136
|
|
Re: Physical screen memory
« Reply #5 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 
|
|
Logged
|
It's always possible, but not necessarily how you first thought. Chin up and try again.
|
|
|
DDRM
Administrator
member is offline
Gender:
Posts: 321
|
|
Re: Physical screen memory
« Reply #7 on: Nov 3rd, 2015, 07:37am » |
|
Hi Ric,
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
|
|
Logged
|
|
|
|
ady
Junior Member
member is offline
Posts: 55
|
|
Re: Physical screen memory
« Reply #8 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
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: Physical screen memory
« Reply #9 on: Nov 3rd, 2015, 10:12am » |
|
on Nov 3rd, 2015, 07:37am, DDRM wrote: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.
--
|
|
Logged
|
|
|
|
ady
Junior Member
member is offline
Posts: 55
|
|
Re: Physical screen memory
« Reply #10 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)
|
| « Last Edit: Nov 4th, 2015, 09:36am by ady » |
Logged
|
|
|
|
Ric
Full Member
member is offline
Gender:
Posts: 136
|
|
Re: Physical screen memory
« Reply #11 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.
|
|
Logged
|
It's always possible, but not necessarily how you first thought. Chin up and try again.
|
|
|
DDRM
Administrator
member is offline
Gender:
Posts: 321
|
|
Re: Physical screen memory
« Reply #12 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
|
|
Logged
|
|
|
|
Ric
Full Member
member is offline
Gender:
Posts: 136
|
|
Re: Physical screen memory
« Reply #13 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
|
|
Logged
|
It's always possible, but not necessarily how you first thought. Chin up and try again.
|
|
|
ady
Junior Member
member is offline
Posts: 55
|
|
Re: Physical screen memory
« Reply #14 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
|
| « Last Edit: Nov 5th, 2015, 09:36am by ady » |
Logged
|
|
|
|
|
