NEWS ARTICLES


    What's News in the PlayBasic world ? - Find out here.



 PlayBasic V1.64O - WIP Round Up #3

By: Kevin Picone Added: May 17th, 2013

Category: All,Upgrade,Beta Testing

The following excerpts are taken from the current PlayBasic V1.64O Work in Program blog during April/May 2013.

PlayBasic V1.64O Beta 6 - Replace$ Issue ?

     Everything has pretty much ground to a halt this week while testing the Amos To PlayBasic conversion tool, we seem to be have uncovered a situation where Replace$ can fail. At least that's what it seems like on the surface. I'm more than a bit tentative pinning the blame on it as yet, after all, this is not my first rodeo and yesterday I'd traced the same issue back to the split to array function. These kind of issues are hard to track down and I'm tentative because the functions might turn out to be ok, but the strings it's passing in could be damaged. Which would definitely hang it, as the string engine assumes the VM always gives it are legal strings.. Either way something is looking fishy somewhere.

     Another possible cause might be from man handling the arrays, the parser builds a tokenized view of the converted source code in nested types. Where there's the program parent type, which in turn allocates it's own line buffer, where each line is a typed array. Which not only means you can have as many programs in memory as need (I only actually need one), but each line of code is a separate 1D typed array. This removes the impact of moving lines and code fragments around. Now when the convert routines parses the tokenize code, the routine skim through looking for the Tagged Tokens. if there's a match if runs the reaction function to the token.

     When changes need to be made to a line of code, it peeks into the array directly. This allows the program to move stuff without every really knowing what it's moving and without having to copy the string fragments directly. The thing is, when you start peeking and poke into an arrays memory, there's no "i think that'll work", it has to work correctly. Otherwise you run the risk of either leaking the string/type resource your moving, or your function corrupts the array data in some way. A leak would just have some information that was there, vanish so easy to track down (in most cases), but corruption can be bit more difficult. If types were being leaked, then we've see parts of the output code would vanish from final code, but it's unlikely to cause some other function down the line to die. Provided the bad routine that leaked that data, didn't insert a none existent thing into the line array. If this occurs now we've a lottery, as the bad data might actually make sense in some causes, but make it blow up in unexpected ways in others.

Anyway, while on the hunt have a found a few tidbits that were worth tweaking, but no smoking gun as yet.. well see..



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.

PlayBasic Code:
    Dim Stuff(100)

    ; assign Stuff() array to some none existent array
     Stuff() = 2000


COMMANDS USED: DIM |


     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.

PlayBasic Code:
	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 MakeBranch function 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 9 - Download

     Posted a live beta of this revision on the forums for testing !



READ BLOG





 

 
     
 
       

(c) Copyright 2002 / 2024 Kevin Picone , UnderwareDesign.com  - Privacy Policy   Site: V0.99a [Alpha]