|
|
|
|
|
|
|
|
|
|
What's News in the PlayBasic world ? - Find out here.
PlayBasic V1.64O - WIP Round Up #4
|
By: Kevin Picone Added: June 3rd, 2013
|
Category: All,Upgrade,Beta Testing,Resource Binding
|
The following excerpts are taken from the current PlayBasic V1.64O Work in Program blog between May->June 2013.
PlayBasic V1.64O Beta 7 - Boot Issues Resource Binding
While the resource binding stuff was added a few revisions ago now, but it's not really been tested in the wild. So wasn't that surprised to find some dependance dramas with attached dll's, in fact was expecting it. The issued turned out to be the order in which the hunks are loaded. If the function declarations are loaded before any bound Dlll they depend upon, then the address resolution will fail.. So the VM will exit when it runs into any function with a null address in user code. Another issue could occur if default command bindings and the user bindings both had resource hunks.
Been testing today's build Beta 7 with Amos-To-PlayBasic and found another compiler dependency in the boot process on my 64bit Win7 system. Turned out to be an easy fix, runs as normal now. Not sure when that started but suspect the V1.64N revisions would have similar dramas in them but haven't tested them. No point now anyway.
PlayBasic V1.64O Beta 9 - Tweaks & Things
Been picking through the map level collision functions looking for an issue with RectHitLevel, initially seemed the query function was pulling the wrong 'spans' from level data, but after some head scratching it turns out the routine pop's a true on any block that has been classified as solid, regardless of if they overlap or not, as they may not. Can't be sure, but are willing to bet there's some similar assumptions with other methods also. Wouldn't mind updating the Mapping stuff again actually, not a huge fan of 'pixel level operations', as masks would be better. Just not sure i can be bothered though.
Edit: Found another query problem with SpriteHitLevel when the sprites collision mode was set to mode 0.
PlayBasic V1.64O Beta 9b - Adding Errors
By now you should realize that entire arrays can be passed around like candy, which allows us to do pretty wacky things. However when we start doing this, the onus is largely put upon our shoulders, us that what we're writing into an Array, is actually a legal array, as it might not be.
Ie.
Dim Stuff(100)
; assign Stuff() array to some none existent array
Stuff() = 2000
While PB would already precheck that the incoming value (on the right hand of the assignment) was actually an array container for us, it would also ignore writes that weren't legal. Making it harder to track down where the data corruption might be coming from.
Limbs=10
Dim Tree(Limbs)
MakeArray Branch()
; create an array to place them in the tree() array.
; so each cell is now conceptually a 1D array
For lp =0 to Limbs
; The MakeBranchfunction exports the 'bank/container' of the array
; as an integer. We can assign then anywhere. There's nothing special
; about them.
Tree(lp)=MakeBranch(rndrange(5,20))
next
; Display the tree
for lp=0 to limbs
if Tree(lp)
; Copy the Branch array container into our redirection/pointer array
; so we now use the redirection arrays to look at the array data
; When PB writes the right handy value into Branch() array it check
; if this value does represent a legal array. if it doesn't it'll error
Branch()=Tree(lp)
; Parse the values into a string
Row$="Branch["+digits$(lp,2)+"] = "
For b=0 to getarrayelements(branch())
row$+=str$(Branch(b))+","
next
; print it out
print trimright$(row$,",")
endif
next
Sync
waitkey
Function MakeBranch(Size)
Dim ThisBranch(size)
For lp =0 to size
ThisBranch(lp)=rnd(1000)
next
EndFunction ThisBranch()
PlayBasic V1.64O Beta 9c - CRF tweaks
Been looking into the CRF libraries the last few sessions. The tweaks started out looking at the loading process, but have progressed to cleaning up the communication protocol between libraries and the legacy VM, plus a few more optimizations. The clean up is a compromise really between the new and the old, but it removes some of the annoying set up work when sharing common resources between the VM with other libraries. But I'll get more into that in some future blog.
CRF formatted fonts have a couple of different flavors, namely 2, 8 or 32 bit. Font's created using the interval commands will be 32bit if your converting a bitmap font,or mostly likely 8bit it's it's a GDI conversion. While picking through some of the routines you can see's these a bit of generic meat on the bones so have trimmed a health slab of that fat out of some render combinations. The one that's showing the biggest benefit would be the 8bit mode when blending to colour. The previous edition seemed to be performing the blend every time a span was drawn. Depending upon the situation, this is generally unnecessary, so can be pre computed.
The result of the changes gives about 20-30% higher through put, which is more than handy.
size=48
LoadFont "Verdana",2,size,0,8
FontBlendColour 2,$00ff00
; Set output to pre blend pixels with FontBlendColour
fontdrawmode 2,2
Do
cls 255
frames++
startinterval(0)
Page_Of_Text(2,$ffff0000)
tt#+=Endinterval(0)
print tt#/frames
Sync
loop
Function Page_Of_Text(ThisFont,C)
oldrgb=getink()
OldFont =GetCurrentFont()
SetFont ThisFont
ink c
For lp=asc("a") to asc("z")
s$+=chr$(lp)
next
s$+=s$ ;+s$+s$
lockbuffer
For ylp=0 to GetScreenHeight() step 10
text xpos,ylp,s$
next
unlockbuffer
SetFont OldFont
ink OldRgb
EndFunction
Testing blend with colour in different depth surfaces
size=48
LoadFont "Verdana",2,size,0,8
FontBlendColour 2,$00ff00
Screen=1
CreateFXimageEx Screen,800,600,32
; Set output to pre blend pixels with FontBlendColour
fontdrawmode 2,2
; ------------------------------------------------------------------
Do
; ------------------------------------------------------------------
rendertoimage Screen
cls 255
frames++
startinterval(0)
Page_Of_Text(2,$ffff0000)
tt#+=Endinterval(0)
rendertoscreen
drawimage Screen,0,0,false
setcursor 0,0
print tt#/frames
print GetImageDepth(Screen)
Sync
loop
Function Page_Of_Text(ThisFont,C)
oldrgb=getink()
OldFont =GetCurrentFont()
SetFont ThisFont
ink c
For lp=asc("a") to asc("z")
s$+=chr$(lp)
next
s$+=s$ ;+s$+s$
lockbuffer
For ylp=0 to GetScreenHeight() step 10
text xpos,ylp,s$
next
unlockbuffer
SetFont OldFont
ink OldRgb
EndFunction
PlayBasic V1.64O Beta 11 - Loading CRF's directly from memory
While looking through the CRF library I've added a way to load the font from memory rather than disc. The following snippet loads a GDI font and saves it out into CRF format. The program then loads this file into a memory bank, then loads the font from the memory bank using the amended loadFont command. Allowing font data to be stored in pack files, encrypted, crunched etc. Ideally what i'd like to do, is implement some method where 'media' in general can be compiled into the exe's resource bindings. Which is only partially possible legacy PB editions.
Filename$="D:\TestCrf.crf"
// Load a true type and convert it to CRF
LoadFont "verdana",20,75,0,8
SaveFont Filename$,20
deletefont 20
// Load the file into a bank
fh=ReadNewFile(filename$)
size=filesize(filename$)
Thisbank=NewBank(size)
ptr=GetBankptr(thisBank)
ReadMemory fh,Ptr,Size
closefile fh
// Load the front from memory. Here instead of passing the load command
// the filename with path, we give it the address of the resource in memory
// in string form.
LoadFont "&"+str$(ptr),30,0
// This bank is no longer of any use, so delete it
DeleteBank ThisBank
// set and draw some text with the font loaded from memory
setfont 30
Print "Hello World"
Sync
waitkey
PlayBasic V1.64O Beta 11b - Loading PNG images directly from memory
So in keeping with yesterdays updating of the CRF loader, here we have a variation of the PNG loader. Just like the CRF stuff we pass the LoadImage (or any of it's variants) the address as a string with the & prefix. The only difference is that this time, the buffered image data needs a 4 header with the size of the image data in it. I'm not too keen on it, but it seems unavoidable.
Today's built only supports PNG's, since that loader was just fetching the data into memory to begin with, the other formats are a little more 'attached' to the disc interface.
Filename$="D:\PlayBasicSig2.png"
// Load the image file into a bank. The picture data needs the size (of the image)
// appended to the header of the structure for this work.
fh=ReadNewFile(filename$)
size=filesize(filename$)
Thisbank=NewBank(size+4)
ptr=GetBankptr(thisBank)
; poke the size into the first 4 bytes
pokebankint ThisBank,0,size
; read the data in after the size.
ReadMemory fh,Ptr+4,Size
closefile fh
// Load the image from memory.
// Just like the LoadFont tests, here we pass the loadIMage command
// the address of the buffer in memory.
LoadImage "&"+str$(ptr),100,8
// This bank is no longer of any use, so delete it
DeleteBank ThisBank
cls 255
drawimage 100,100,100,true
Sync
waitkey
Loading Map Blocks directly from memory
Since the Map library uses the image library to load media these days we're able to expose the functionality to loading blocks also.
Filename$="D:\PlayBasicSig2.png"
// Load the image file into a bank. The picture data needs the size (of the image)
// appended to the header of the structure for this work.
fh=ReadNewFile(filename$)
size=filesize(filename$)
Thisbank=NewBank(size+4)
ptr=GetBankptr(thisBank)
; poke the size into the first 4 bytes
pokebankint ThisBank,0,size
; read the data in after the size.
ReadMemory fh,Ptr+4,Size
closefile fh
// Load the image from memory.
// Just like the LoadFont tests, here we pass the loadIMage command
// the address of the buffer in memory.
t=timer()
LoadafxImage "&"+str$(ptr),100
BlockWidth=32
BlockHeight=32
Map=NewMap(10)
Level=NewLevel(Map,20,10)
LoadMapGFX "&"+str$(ptr),Map,BlockWidth,BlockHeight,-1,4
Tile=0
For ylp =0 to GetImageHeight(100) step BlockHeight
For xlp =0 to GetImageWidth(100) step BlockWidth
PokeLevelTile Map,Level,xlp/BlockWidth,ylp/BlockHeight,Tile
Tile++
next
next
leveldrawmode map,level,2
cls 255
drawimage 100,100,100,true
drawmap Map,level,100,300
DeleteBank ThisBank
Sync
waitkey
PlayBasic V1.64O Beta 12 - Loading BMP/TGA images directly from memory
So tonight's little coding session adds load from memory support for BMP and TGA image formats. From the limited testing it's had tonight, it all seems to be working pretty well. When picking through the loader, the easy solution just seemed to be replace the 'file' fetching commands with an ambiguous interface. Which meant rolling a bit of extra set up code, but once that was done the decode logic is identical in both modes.
Just like loading PNGs from memory, the loader needs the size of the resource (in bytes) poked into the data header. This is really in an effort to trap some load possible errors up front, but existing loaders don't really bother with errors too much. Some formats will require it, others not so much.
Anyway, what all this now allows you to do, is create custom pack files with at least the image media in them.
READ BLOG
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|