So for each position on the screen that the ball can be, you make nine decisions (currently based on testing the result of nine POINT statement), each one to determine to whether the graphic below a certain pixel is either:
- transparent; - solid; or - deadly? Am I right to think that, taking an overview, you need to know whether each tested pixel is transparent or solid for bouncing, but only whether any of them at all is deadly? i.e. for the purposes of life or death, all you care about is whether any of the pixels at all is deadly, you don't care how many or which? In that case you can say that when the ball is at position (x, y) then you care work out how to react from ten Boolean values. The first nine are whether or not there is something solid underneath the corresponding pixel. The tenth is whether any of the nine pixels are deadly. If you do any subsequent processing to reduce the amount of information (e.g. just deciding between 16 types of bounce and whether death results) then you can simplify things further. But I daren't assume. You can package the ten Booleans into 10 binary digits. In Mode 4, each pixel is represented in memory by 4 bits. So you can store the 10 as 2.5 Sam pixels (so, practically speaking, 3). So you could loop through every pixel of your level before the player starts, work out the values of the ten values, combine them into 3 Sam pixels then plot them to screens that the player will never see. When the player is actually playing, do 3 POINTs based on the position of the centre of the ball to pull back the 3 pixels, then decode them to get the values you're actually interested in. For example (the exact syntax may be a bit scratchy, it's been quite a few years for me): 10 LET PCOL = 0 20 IF POINT(X, Y) > 0 THEN LET PCOL = PCOL+1 30 IF POINT(X+1, Y) > 0 THEN LET PCOL = PCOL+2 40 IF POINT(X-1, Y) > 0 THEN LET PCOL = PCOL+4 50 IF POINT(X, Y-1) > 0 THEN LET PCOL = PCOL+8 60 SCREEN <whatever>: PLOT (X, Y, PCOL) then, later... 70 SCREEN <whatever>: LET PCOL = POINT(X, y) 80 IF PCOL BAND 1 THEN PRINT "POINT (X,Y) is > 0" 90 IF PCOL BAND 2 THEN PRINT "POINT (X+1,Y) is > 0" 100 IF PCOL BAND 4 THEN PRINT "POINT (X-1,Y) is > 0" 110 IF PCOL BAND 8 THEN PRINT "POINT (X,Y-1) is > 0" So, you at least reduce 9 POINTs to 3. Of course, there is only a benefit if BAND is cheaper than POINT, which it probably will be. Also, you might need "IF PCOL BAND 1 > 0" rather than just "IF PCOL BAND 1" depending on whether Sam BASIC will assume that "IF PCOL BAND 1" on its own just means that the test is true if PCOL BAND 1 is anything other than 0. On Wed, Sep 24, 2008 at 8:55 PM, Calvin Allett <[EMAIL PROTECTED]> wrote: > Hey Thomas :) > > The values for the variables are just 0 - 15 for the colour of that pixel, > set > up with the levels as follows :- > > 0- > 1 and 2 - > 3 - > 9 - another black for drawing spikes, or for the border of enemies - lose > life > all others are for drawing scenery/solid > > Im afraid I don't quite get that :( I'm terribly sorry, is a nibble half > a byte? I understand what your trying to say i.e. having another > way that I can interpret the data, for speed, just not getting > the idea... I must stress though that I need to be able to 'push' > the ball from many different pixels within the same frame sometimes, > as the levels can be a lot like worms or Lemmings with regard to 'down > to the pixel' collision, actually drew some single pixels onto a test level, > and 'trialled' up them, although it'll still miss them if falling fast :) > > Im the worst student ever :P I actually just remembered an email > you sent me last year off list trying to help me with my speed problem, > and you explained an idea very well, in quite a few paragraphs and I > had to tell you I didn't understand :( lol (well I can only laugh ;) ) I'm > gonna hunt that out to see what it was... > > anyways, I ramble... > > P.S. the array thing, I could try storing the screen data in an array, and > see > if that's faster than point, but don't wanna open up extra pages yet to > basic > as both SAM and MasterBasic massively seem to crash once a prog > gets bigger than about 60-64 K > > Is it BAND I would use to check nibbles also? > > Thomas Harte <[EMAIL PROTECTED]> wrote: > > What sort of values can those nine variables take on? If it's just two > possibilities (e.g. overlapping or not overlapping) then you could > package them into nibbles in fours, store the nibbles as pixel colours > to unseen screens and reduce your number of POINTs from 9 to 3. It's > essentially pre-calculating the results for each pixel on screen and > storing them in an integer array that BASIC understands how to index. > > On 24 Sep 2008, at 17:36, Calvin Allett wrote: > >> Firstly would like to apologize to Thomas and Geoff for not getting >> back to this, ended up going out on p*ss other day and completely >> forgot I'd posted on here, hehe (been gonna ask so many times over >> past year :) )... >> >> anyways, Yahoo won't let me reply to your emails for some reason, so >> I'll just have to post here. >> >> Yeah Thomas, as Geoff said about calculating the value's of pixels >> myself, and as you've found out, way to slow, I actually tried the >> same thing last year with variables, i.e. just storing values in RAM >> myself and updating and seeking them from their locations instead of >> using variables, thinking it would cut out looking up the variables, >> but that too ended up slower :( Really am trying every trick I can >> to make Basic be capable of the things I want, and must say that the >> amount of months I spend polishing and speeding things up with >> tricks It'd be quicker to learn MC, but as I've said I honestly >> wouldn't enjoy coding then ;) >> >> The thing you said about keeping a copy of the screen and having >> pixels to check for what happens to the ball is a very good idea, >> already doing that with a Screen 3 (as 1 and 2 are used for screen >> flipping), so that when there are sprites on screen, I can still >> check for background colour and have movement correct... >> >> Did think about using a 4th say, as you suggest to perhaps make >> finding of the pills a bit easier, but that would mean doing yet >> more more POINT test, and I really need to be doing all the others >> anyway (L,R,T,B,B2,B3,B0,BR and C) as basically the game is one big >> collision detection engine, everything from the movement, >> background, enemy collision and pill finding is done using those 9 >> variables, and they all need to be done every frame :( , which leads >> me on to what >> geoff discussed. >> >> Geoff, it's a crying shame that SAM or Masterbasic hadn't offered >> integers, being a lamer, hehe, I wouldn't know how much time it >> would save, but anything counts right :) I made sure with >> calculations to try and use integer only for this game (apart from Y >> variable which sometimes isn't)... >> >> Couldn't understand the MC you posted but I get what you mean about >> only finding address of coordinate and then using offsets to speed >> up routine, I notice there was very little code, were those few >> lines all it takes to find the value's and move on to next point to >> check etc? ... I always imagine that for any 1 command in basic >> it'll take perhaps 10-30 lines (or more) in MC to accomplish the >> same thing. >> >> The way it works at moment it can't just always check say the pixels >> to the left if the ball is heading that way, as the way levels are >> drawn you might be jumping down a curved passage way, so that each >> frame the ball is getting projected out and away from anything it >> comes into contact with, and sometimes that might be from all around >> the ball. I finally got it so that even though you can get very >> close, the ball never lets you squeeze into the scenery, so that >> makes it look nicer. >> >> anyways, I don't really know what to do at the moment, but will try >> and post a couple of vids up later so it can be seen how much it's >> slowed down with more point checks... ;) >> >> Thanks again lads, without being able to talk about coding I'd probs >> still be across the road getting pi**ed EVERYday with 10 pissheads >> instead of enjoying the SAM, lol *_+ >> >> Cal... >> >> >> > > >
