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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: That's looking pretty solid dude J Si From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Calvin Allett Sent: Friday, September 26, 2008 1:29 PM To: sam-users@nvg.ntnu.no 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 !
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Calvin Allett Sent: Friday, September 26, 2008 1:29 PM To: sam-users@nvg.ntnu.no 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 !
RE: Speed issue's with POINT (x,y)
That's looking pretty solid dude J Si From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Calvin Allett Sent: Friday, September 26, 2008 1:29 PM To: sam-users@nvg.ntnu.no 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 !
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 [EMAIL PROTECTED] wrote:Thats looking pretty solid dude J Si From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Calvin Allett Sent: Friday, September 26, 2008 1:29 PM To: sam-users@nvg.ntnu.no 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 !
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 !
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 !
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...
Re: Speed issue's with POINT (x,y)
On Thu, 18 Sep 2008 15:37:51 +0100, Geoff Winkless [EMAIL PROTECTED] wrote: test-up would therefore be [snip] D'oh; of course this is wrong (one line in mode 4 is 128 bytes, not 256) so you'd have to add 128 to IX (or HL) rather than increasing I (or H) but you get the idea. G
Re: Speed issue's with POINT (x,y)
You're quite right — some hasty testing in Sim Coupe reveals that it is much slower. I was imagining that POINT might go through some arcane paths with all the xos/yos/xrg/yrg stuff. If you have the memory to spare, could you maybe skip over the problem by allocating a new screen that is never shown to the player, then in advance (maybe just after the level has been loaded?) plotting a colour at each position that represents what should happen when the ball is there? It'd mean you could cut yourself down to using a single POINT. On 18 Sep 2008, at 15:37, Geoff Winkless wrote: On Thu, 18 Sep 2008 13:26:15 +0100, Thomas Harte [EMAIL PROTECTED] wrote: Maybe something like the following to get the colour of the pixel at (x, y): 10 LET A=IN 252 BAND 31 20 LET BASE=(A+1)*16384 30 LET ADDR = BASE + (x/2) + y*128 40 LET BYTE = PEEK(ADDR) 50 IF x BAND 1 THEN LET COL = BYTE/16 ELSE LET COL = BYTE BAND 15 I can't believe that would be any quicker (in fact I'd be amazed if it's not slower) than POINT(). The way to improve the speed in a generic way is to write machine code that checks the edges of a bitmap you pass it and tests the appropriate points on the screen. The _fastest_ way is to write a specific set of checks based on the sprite and the direction of movement. Basically, let's say you figure out that if you're moving upwards you need to test pixels 2 to 6 on line 0 and pixels 1 and 7 on line 1. Your code for test-up would therefore be LD A, (IX+1) # pixels 2+3 OR A, (IX+2) # pixels 4+5 RET NZ OR A, (IX+3) # pixels 6+7 INC I:IX (or whatever your assembler uses for that non-instruction) OR A, (IX) # pixels 0+1 line 1 AND 0F # isolate rightmost pixels RET NZ OR A, (IX+3) # pixels 7+8 line 1 AND f0 # isolate leftmost pixel RET IIRC if you call this with USR you get the value in A as the result (or is it BC? Can't remember), so you can just IF USR(upcode)0 THEN GOTO HIT There are ways of passing parameters to USR functions, I can't remember how though :( I'm also not sure if using IX is better than INCing H and L (probably not) The problem with POINT (or similar) is that it has to completely recalculate the positions in memory for every check. That's slowed down even further because each time it has to access the values from BASIC's variable stack which (since it's all floating-point and they're stored in a non-optimal way) is ridiculously slow (it's a shame Andy Wright didn't see fit to add integer variables like you get in BBC Basic, for example) Geoff
