Calvin Allett | 24 Sep 18:34

Speed issue's with POINT (x,y)

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


Thomas Harte | 24 Sep 21:21

Re: Speed issue's with POINT (x,y)

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

Calvin Allett | 24 Sep 21:55

Re: Speed issue's with POINT (x,y)

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 <tomh.retrospec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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...
>
>
>


Thomas Harte | 25 Sep 15:47

Re: Speed issue's with POINT (x,y)

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
<calvin_allett@...> 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 <tomh.retrospec@...> 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...
>>
>>
>>
>
>
>

Calvin Allett | 26 Sep 21:51

Re: Speed issue's with POINT (x,y)

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

Yes, that's perfectly the situation :)  Will need to use an 11th for bouncy
stuff, and could use a 12th to check another pixel above the ball which
would refine movement sometimes :)

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

I just check all the value's and push or bounce the ball away from them :)

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

Now that I actually get this I like the idea, and it makes sense for the 'static' levels, will have to do new code for moving enemies, as they wouldn't be picked up by the new checking as I was using the POINTS to also find them, but without speeding the engine up I wouldn't be able to throw any in anyhow ;)

-
-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 : PLOT (X, Y, PCOL)
-
-then, later...
-
-70 SCREEN : 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.

Thank you for providing example source code :D I will try and change the
game engine tomorrow and see how it works :) This could very well
be just the idea I was needing ;) (I took out just 4 of the POINT checks before
just to see the speed gain, and it was VERY noticeable :D )

I will have to keep the current engine for certain levels however, as
I want some of them to do full screen rotations (prerotating them
on PC, and flipping through screens on SAM), and these ones will need the
engine that checks the 'current' POINTs in real time.

Quite excited hoping I can grab some speed back once I've tried this, so thanks
again for your input !

Cal...

P.S. I put a video up on my YouTube page, but it hasn't gone live yet, will
post when  it does !

Calvin Allett | 26 Sep 22:28

Re: Speed issue's with POINT (x,y)

http://www.youtube.com/watch?v=2RenBQ5GD24

That's nearly half the speed that the engine was just 4 weeks ago eek, hehe



P.S. I put a video up on my YouTube page, but it hasn't gone live yet, will
post when  it does !


Simon Cooke | 27 Sep 10:15

RE: Speed issue's with POINT (x,y)

That’s looking pretty solid dude J

 

Si

 

From: owner-sam-users-w01uWLE43QoXWF+eFR7m5Q@public.gmane.org [mailto:owner-sam-users-w01uWLE43QoXWF+eFR7m5Q@public.gmane.org] On Behalf Of Calvin Allett
Sent: Friday, September 26, 2008 1:29 PM
To: sam-users-w01uWLE43QoXWF+eFR7m5Q@public.gmane.org
Subject: Re: Speed issue's with POINT (x,y)

 

http://www.youtube.com/watch?v=2RenBQ5GD24

That's nearly half the speed that the engine was just 4 weeks ago eek, hehe



P.S. I put a video up on my YouTube page, but it hasn't gone live yet, will
post when  it does !

 

 

Calvin Allett | 27 Sep 12:24

RE: Speed issue's with POINT (x,y)

Thanks Simon :) Of course it's for the 20Mhz SAM, so I really
should have it running a lot faster, even in basic...

Simon Cooke <simon-XDw3mcOs8dPfBZEFBb7SSg@public.gmane.org> wrote:

That’s looking pretty solid dude J

 

Si

 

From: owner-sam-users-w01uWLE43QoXWF+eFR7m5Q@public.gmane.org [mailto:owner-sam-users-w01uWLE43QoXWF+eFR7m5Q@public.gmane.org] On Behalf Of Calvin Allett
Sent: Friday, September 26, 2008 1:29 PM
To: sam-users-w01uWLE43QoXWF+eFR7m5Q@public.gmane.org
Subject: Re: Speed issue's with POINT (x,y)

 

http://www.youtube.com/watch?v=2RenBQ5GD24

That's nearly half the speed that the engine was just 4 weeks ago eek, hehe



P.S. I put a video up on my YouTube page, but it hasn't gone live yet, will
post when  it does !

 

 


Calvin Allett | 27 Sep 14:52

RE: Speed issue's with POINT (x,y)

another vid
http://www.youtube.com/watch?v=14m21hySxG8

Older versions, one faster, one slower:-

http://www.youtube.com/watch?v=U0ksam2anMI
http://www.youtube.com/watch?v=L8s4yb8zMMQ

Cal...


Calvin Allett <calvin_allett-/E1597aS9LT10XsdtD+oqA@public.gmane.org> wrote:

Thanks Simon :) Of course it's for the 20Mhz SAM, so I really
should have it running a lot faster, even in basic...

Simon Cooke <simon <at> popcornfilms.com> wrote:
That’s looking pretty solid dude J

 

Si

 

From: owner-sam-users-w01uWLE43QoXWF+eFR7m5Q@public.gmane.org [mailto:owner-sam-users <at> nvg.ntnu.no] On Behalf Of Calvin Allett
Sent: Friday, September 26, 2008 1:29 PM
To: sam-users-w01uWLE43QoXWF+eFR7m5Q@public.gmane.org
Subject: Re: Speed issue's with POINT (x,y)

 

http://www.youtube.com/watch?v=2RenBQ5GD24

That's nearly half the speed that the engine was just 4 weeks ago eek, hehe



P.S. I put a video up on my YouTube page, but it hasn't gone live yet, will
post when  it does !

 

 



Thomas Harte | 29 Sep 14:57

Re: Speed issue's with POINT (x,y)

I agree with Simon; I especially like the way the ball crushes itself
to go through short spaces.

On Sat, Sep 27, 2008 at 1:52 PM, Calvin Allett
<calvin_allett@...> wrote:
> another vid
> http://www.youtube.com/watch?v=14m21hySxG8
>
> Older versions, one faster, one slower:-
>
> http://www.youtube.com/watch?v=U0ksam2anMI
> http://www.youtube.com/watch?v=L8s4yb8zMMQ
>
> Cal...
>
>
> Calvin Allett <calvin_allett@...> wrote:
>
> Thanks Simon :) Of course it's for the 20Mhz SAM, so I really
> should have it running a lot faster, even in basic...
>
> Simon Cooke <simon@...> wrote:
>
> That's looking pretty solid dude J
>
> Si
>
> From: owner-sam-users@...
[mailto:owner-sam-users@...] On
> Behalf Of Calvin Allett
> Sent: Friday, September 26, 2008 1:29 PM
> To: sam-users@...
> Subject: Re: Speed issue's with POINT (x,y)
>
> http://www.youtube.com/watch?v=2RenBQ5GD24
>
> That's nearly half the speed that the engine was just 4 weeks ago eek, hehe
>
> P.S. I put a video up on my YouTube page, but it hasn't gone live yet, will
> post when  it does !
>
>
>
>

Calvin Allett | 30 Sep 00:25

Re: Speed issue's with POINT (x,y)

Thanks Thomas :) Well I'm pleased some people like the look of it so far,
nearly ditched it when it started slowing down... I'm hoping it'll be my first decent game for SAM, hehe ... I spent a good 6 hours on it yesterday, managed to get rid of 3 of the point checks, without drastically changing how it trials, and with some other changes managed to speed it up about 30 - 40 % when your in the air (which is most of the time), so it's back to
the speed I wanted... Now to add in portals and a rope to finish off the 'trialing' mechanics before enemies and anims... Probs be back to ask for help with the rope, ;)

I'd love to try and draw some rotated cogs for a level and watch them pick up
the ball and carry it between them, animated chains to working like conveyor belts... but not sure best way to draw them yet. Animated scenery has always been the main point of this game, and ahm still
stuck with static scenery :( (I did hoy in some earthquake code earlier though, like two lines of code, hehe)...

P.S. Now down to 5 main POINT checks per frame, so getting excited about
trying to knock 4 of those down to 1 check, and that should make a really fast engine for static levels, whereby loads of cpu time left for a few enemies... and polish the current engine for animated and/or rotating levels, whereby only one enemy will be possible probably, so will have to switch tiles occasionally to form hazards :)

Cal...

Thomas Harte <tomh.retrospec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

I agree with Simon; I especially like the way the ball crushes itself
to go through short spaces.

On Sat, Sep 27, 2008 at 1:52 PM, Calvin Allett
wrote:
> another vid
> http://www.youtube.com/watch?v=14m21hySxG8
>
> Older versions, one faster, one slower:-
>
> http://www.youtube.com/watch?v=U0ksam2anMI
> http://www.youtube.com/watch?v=L8s4yb8zMMQ
>
> Cal...
>
>
> Calvin Allett wrote:
>
> Thanks Simon :) Of course it's for the 20Mhz SAM, so I really
> should have it running a lot faster, even in basic...
>
> Simon Cooke wrote:
>
> That's looking pretty solid dude J
>
> Si
>
> From: owner-sam-users-w01uWLE43QoXWF+eFR7m5Q@public.gmane.org [mailto:owner-sam-users-w01uWLE43QoXWF+eFR7m5Q@public.gmane.org] On
> Behalf Of Calvin Allett
> Sent: Friday, September 26, 2008 1:29 PM
> To: sam-users-w01uWLE43QoXWF+eFR7m5Q@public.gmane.org
> Subject: Re: Speed issue's with POINT (x,y)
>
> http://www.youtube.com/watch?v=2RenBQ5GD24
>
> That's nearly half the speed that the engine was just 4 weeks ago eek, hehe
>
> P.S. I put a video up on my YouTube page, but it hasn't gone live yet, will
> post when it does !
>
>
>
>
@public.gmane.org>/E1597aS9LT10XsdtD+oqA@public.gmane.org> <at> yahoo.co.uk>


Gmane