Author |
Topic: Physical screen memory (Read 1617 times) |
|
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
|
|
|
|
ady
Junior Member
member is offline
Posts: 55
|
|
Re: Physical screen memory
« Reply #15 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
.stor
mov ecx,[count]
mov eax,^FF$(0)
mov ebx,[eax]
mov eax,^FF$(1)
mov eax,[eax]
.stor1
push ecx
push ebx
push eax
push @hwnd%
call "MessageBox"
inc dword [count]
cmp dword [count],&10
jb stor
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
|
|
Logged
|
|
|
|
KenDown
Full Member
member is offline
Posts: 181
|
|
Re: Physical screen memory
« Reply #16 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.
|
|
Logged
|
|
|
|
|
