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