This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - MGOS
Pages: 1 ... 13 14 [15] 16 17 ... 23
211
« on: April 27, 2012, 11:52:44 am »
The next thing would be an Tilemapper, and then I will try to convert other stuff to this perspective, like buildings or vehicles.
A huge advantage is that this routine is incredibly fast (it uses only add, subtract and shift operations) so even complex stuff can be displayed with still an decent speed. The main speed problem are indeed the calculations to detect what is displayed first, what next etc. In my 3D editor program I always draw everything, so with the number of cubies the speed drops.
212
« on: April 27, 2012, 10:39:18 am »
Since I always wanted to make some 3D ish stuff in axe, I tried to figure out how isometric graphics work and made a whole bunch of functions to draw pseudo 3D tiles on the screen and to display an 8x8x8 bit array as a model made from little cubies. It supports 3-level greyscale. I will post code or a tutorial later if you are interested, this is just a preview of my upcoming stuff and what I've done so far. ? ? ? ? ?
213
« on: April 21, 2012, 08:08:44 am »
After a short break I finally got back to do some coding, because my friends wanted this game:
You may know the Tron game, and this is something similar although it's inspired by the German game called "Achtung, die Kurve". The problem was, that curves are impossible / ugly on the calc screen, so this game is about corners.
You can play against a friend or against the AI of the calc - which... does its job, but doesn't know anything about strategic gameplay - in five different speeds/difficulties.
The program also contains some statistics, the number of wins of each player and a local highscore.
There are two versions, an English version and a German one, both have the same gameplay though.
Check the one of the readme files in the zip for further information.
Powerups will come, but don't expect much - I want to keep it a MINI game.
214
« on: April 16, 2012, 11:29:08 am »
Mine is now a drawing of me made in 5 minutes by an awesome guy in my class using MS paint...
215
« on: April 16, 2012, 12:24:13 am »
You can access the data by using {L1+index}->whatever
Index is the position in the array; it can be a variable or a constant. If it is 0, you get the first element, if it is 1 you get the second element etc.
To store sth in the array, use the syntax the other way round: whatever->{L1+index}
216
« on: April 04, 2012, 05:02:34 pm »
That's actually an interesting thought...  Maybe I'll add that later... firstly, my next step is to get the main program working, and then we'll see.
217
« on: April 04, 2012, 04:51:12 pm »
What about using an arbitrary buffer in the program file? I'm gonna have grayscale too, but I think I can afford having that buffer.
218
« on: April 04, 2012, 04:15:03 pm »
Again, thanks, but I came up with another, also very fast (maybe faster than yours  ) routine for fixed memory flood filling by myself. It used besides the drawing buffer(s) a stack (L1) and a 768 byte second buffer. You can imagine that it works like memory swapping on a computer, if the RAM is full, data will be stored on the hard drive instead. My routine searches iterative for pixels to fill using the stack, but if the stack overflows, it swaps to the other buffer using the slower searching routine. When the stack empties, the data will be put back on the stack. Like this I can achieve small areas filled extremely fast and bigger areas also with decent speed. The only disadvantage is that it uses another 768 byte buffer (L3 when not uing grayscale) and L1 as stack. But I'm able to carry that. :.FLOOD
:Buff(768)→GDB1
:15→A .Coordinates of "paint bucket"
:15→B
:0→S→D→C .Screen buffer size, data buffer size and counting var
:PUS(A,B) .Add the first pixel to stack
:While S+D . as long there's sth in the buffers
:C++
:POP() .Get a pixel
:!If pxl-Test(P,Q) .Test if it's off
:Pxl-On(P,Q) .if yes, turn it on
:P?PUS(P-1,Q) .Put pixels around it on the stack
:P-95?PUS(P+1,Q)
:Q-63?PUS(P,Q+1)
:Q?PUS(P,Q-1)
:End
:C^64??DispGraph .Only display every 64 time; not needed
:ReturnIf getKey(15)
:End
:DispGraph
:Return
:
:Lbl PUS .Push algorithm
:ReturnIf pxl-Test(r1,r2) .only push if the pixel is white
:If D-357 .if stack isn't full yet
:r1→{D*2+L1} .add to stack
:r2→{D*2+1+L1}
:D++ .increment stack pointer
:sub(CHKr,r1,r2) .check if pixel is black on the back buffer, if yes, remove it there
:Else!If pxl-Test(r1,r2,GDB1) .if stack is full, make sure that the pixel isn't in memory yet
:Pxl-On(r1,r2,GDB1) .turn it on on the back buffer
:S++ .increment buffer size
:End
:Return
:
:Lbl POP .Pop algorithm
:If D .if there's something on the stack
:D-- .decremt stack pointer
:{D*2+L1}→P .get the coordinates from the stack
:{D*2+1+L1}→Q
:CHK(P,Q) .check if pixel is black on the back buffer, if yes, remove it there
:Else .if stack empty
:For(Q,0,63 .go on searching the back buffer (slow...)
:For(P,0,95
:If pxl-Test(P,Q,GDB1) .if you got a pixel
:Pxl-Off(P,Q,GDB1) .turn it off
:S-- .decrement the buffer size
:Return .return to main
:End
:End
:End
:End
:Return
:
:Lbl CHK .check algorithm
:If pxl-Test(r1,r2,GDB1) .check if pixel is black on the back buffer
:Pxl-Off(r1,r2,GDB1 .if yes, remove it there
:S-- .decrement the buffer size
:End
:Return
219
« on: April 03, 2012, 05:18:26 pm »
That's clever for this use.
220
« on: April 03, 2012, 04:52:37 pm »
Well, do you know what a pxl-test returns outside of the screen? Do I have to do exception handeling right there?
221
« on: April 03, 2012, 04:19:26 pm »
Wow, Xeda, that's awesome! Thanks, that helped me a lot.
222
« on: April 03, 2012, 04:11:41 pm »
Hmm I see. As for two different e-mails do you mean just like having two Gmail tabs open and clicking submit on both at once? 
You'd have two morse keyboards and you can write both e-mails the same time, because you need just 2/3 fingers for one keyboard and you can't miss the keys because of there big size.
223
« on: April 03, 2012, 11:22:22 am »
I'm not sure if this counts to necroposting, but because I need something like that atm I'm now curious to see Xeda's algorithm.
224
« on: April 03, 2012, 08:03:58 am »
Here's one jacobly made
http://ourl.ca/151805
Wow... that one's cool. now I'm wondering if I should stick with the tough work of converting it to axe or think of another solution by myself. Edit: I rewrote my algorithm that it needs only a second 768 B buffer like Xeda wrote, but it is d*mn slow (because of the search algorithm I used) Screeny at 4x speed:
225
« on: April 03, 2012, 04:38:46 am »
There was a floodfill routine posted earlier that used no extra memory and so can never cause a crash, but I can't find the link anymore 
That's a bummer.
Pages: 1 ... 13 14 [15] 16 17 ... 23
|
Show Posts