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...
