BBC BASIC for Windows
« Physical screen memory »

Welcome Guest. Please Login or Register.
Apr 5th, 2018, 10:01pm



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  Notify Send Topic Print
 hotthread  Author  Topic: Physical screen memory  (Read 1612 times)
Ric
Full Member
ImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 136
xx 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.
User IP Logged

It's always possible, but not necessarily how you first thought. Chin up and try again.
DDRM
Administrator
ImageImageImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 321
xx 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
User IP Logged

Ric
Full Member
ImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 136
xx 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!
User IP Logged

It's always possible, but not necessarily how you first thought. Chin up and try again.
Ric
Full Member
ImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 136
xx 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?
User IP Logged

It's always possible, but not necessarily how you first thought. Chin up and try again.
DDRM
Administrator
ImageImageImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 321
xx Re: Physical screen memory
« Reply #4 on: Nov 1st, 2015, 7:05pm »

Hi Ric,

OK, that's a whole different can of worms! smiley

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
User IP Logged

Ric
Full Member
ImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 136
xx 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 grin
User IP Logged

It's always possible, but not necessarily how you first thought. Chin up and try again.
David Williams
Developer

member is offline

Avatar

meh


PM

Gender: Male
Posts: 452
xx Re: Physical screen memory
« Reply #6 on: Nov 3rd, 2015, 04:16am »

A couple of years ago I developed a library of sprite/bitmap plotting routines called GFXLIB.

Many of the games (including Vapiki) on this website use this library: http://www.jeroengroenendaal.com/repository/bb4w/index-2.html

If all you want to do is plot sprites, then GFXLIB is simple to use. It may suite your needs.

If you're interested, let me know.


David.
--

https://www.youtube.com/channel/UC1E2sxhlc9h9C82q6RFvAWQ
User IP Logged

DDRM
Administrator
ImageImageImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 321
xx 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
User IP Logged

ady
Junior Member
ImageImage


member is offline

Avatar




PM


Posts: 55
xx 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
User IP Logged

David Williams
Developer

member is offline

Avatar

meh


PM

Gender: Male
Posts: 452
xx 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.
--
User IP Logged

ady
Junior Member
ImageImage


member is offline

Avatar




PM


Posts: 55
xx 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 » User IP Logged

Ric
Full Member
ImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 136
xx 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.
User IP Logged

It's always possible, but not necessarily how you first thought. Chin up and try again.
DDRM
Administrator
ImageImageImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 321
xx 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
User IP Logged

Ric
Full Member
ImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 136
xx 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
User IP Logged

It's always possible, but not necessarily how you first thought. Chin up and try again.
ady
Junior Member
ImageImage


member is offline

Avatar




PM


Posts: 55
xx 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 » User IP Logged

Pages: 1 2  Notify Send Topic Print
« Previous Topic | Next Topic »

| |

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