Again, no expert [noparse];)[/noparse] but I would think that since you know you have a 20x23 display, that you have 460 positions.
to calculate your x and y as one number, it would be: position := (x * 20) + y
position := x + (y * 23)
to get back your x and y from the number (I think) woud be: position_y := position // 20
position_x := (position - position_y) / 20
position_x := position // 23
position_y := (position - position_x) / 23
[noparse][[/noparse]Edit:] I was thinking backwards the first time
...that is assuming that the modulus operator // works like % in a language like C [noparse][[/noparse]Edit:]I will do some research on this later unless someone knows offhand
Post Edited (trodoss) : 11/14/2008 12:06:07 AM GMT
@OBC, actually, now that I have had time to think about it, you might want to investigate the mention of 'struct's previously in the thread (look at Bagger's code example) The reason being that you are looking to reduce the number of variables, so organizing like variables would be what you are ultimately after.
Since you know you will have more more than one enemy, each of which will have an x and y position (and possibly what direction are they moving in, are they alive/visible or dead/invisible--not being drawn, and how many gems have they stolen), if you have a single struct that describes your 'baddie' the easier it will be to manage.
The same could apply for your 'drillable blocks' (an individual counter for how long they will stay drilled maybe, as well as their x and y position).
I've implemented your character move stuff in the next release of Loadrunner (to-be-posted)
I've discovered that I need to do some serious work on timers now. The animation looks almost spot-on now.
I was going to put don't use a value like 23, use something more computer friendly [noparse];)[/noparse] like 32
that way, positionx would be just position&31 and positiony would be position>>5 ( as >>5 is faster than /32 )
however, since your total value would be more than 256, it uses two bytes anyway.
So why not have one byte each [noparse]:D[/noparse] then you don't need to do any division
so your struct would be something like
if your screen is 32·bytes wide · position := scrbase + byte[noparse][[/noparse]badptr][noparse][[/noparse]positiony] << 5 + byte[noparse][[/noparse]badptr][noparse][[/noparse]positionx]
'···············=···· base·· +··· y * 32··· + x
if your screen is 32·words wide · position := scrbase + ( byte[noparse][[/noparse]badptr][noparse][[/noparse]positiony] << 5 + byte[noparse][[/noparse]badptr][noparse][[/noparse]positionx] ) << 1
'···············=···· base·· +···( y * 32· + x·) * 2
if your screen is·40·bytes wide · position := scrbase +·( byte[noparse][[/noparse]badptr][noparse][[/noparse]positiony] << 5·) + ( byte[noparse][[/noparse]badptr][noparse][[/noparse]positiony] <<·3 )·+ byte[noparse][[/noparse]badptr][noparse][[/noparse]positionx]
'···············=···· base·· +··(· y * 32 )··+ ( y * 8·) + x
'·············· =···· base·· +··y * 40 + x
if your screen is·40·words wide · position := scrbase + ( ( byte[noparse][[/noparse]badptr][noparse][[/noparse]positiony] << 5 ) + ( byte[noparse][[/noparse]badptr][noparse][[/noparse]positiony] <<·3 )·+ byte[noparse][[/noparse]badptr][noparse][[/noparse]positionx] ) << 1
'···············=···· base·· +··( ( y * 32 )··+ ( y * 8·) + x ) *2
'·············· =···· base·· +··( y * 40 + x ) * 2
Thanks again!· I had·forgotten that Spin had bitwise shift operators, and that would indeed be faster.·
OBC,·are you using this·to calculate screen/map position, or are you trying to save variable space?
[noparse][[/noparse]Definately take with a grain of salt...] My recommendation would be to not sacrafice future 'readablitity' (when you have not·looked at the code in weeks/months and find a bug) by trying to 'pack' too much.· I have been guilty of that too many times and have been forced at that point to rewrite the code just to figure out what is causing the problem.
As far as· timing, make use of counters.· If you have a structure that represents the 'baddies,' certianly you could·add·in a counter to handle·that baddie's relative 'speed'·(how many cycles of 'delay' they have·in relation·to other things).· When that counter reaches their delay, then reset it.· That way, everything operates on a single 'clock,' but each individual object you are animating can be faster/slower than others, and appear to have their own 'virtual' clock in your game loop.··
[noparse][[/noparse]Edit:] Also, when something moves off the screen or dies, definately have (as Baggers has in his example) a variable that represents wether or not it is alive/visible.· That way you can check with an IF... before you try to animate/draw·the object, freeing up time otherwise dedicated to processing that object.
Pretty much, Baggers (brilliant, as always [noparse];)[/noparse] )·had already put those concepts in the struct code above, I just wanted to make sure (if you didn't already know) *why* he was putting things in the structure example he was showing.
Actually what I'm thinking is how I can record the position of the open blocks when the screen is updated
from the original map. Having X & Y in one variable makes it easier to store the data.
I will probably not implement this until I do a complete re-write down the road, but I'm sure I'll want
the ability for the next project. Determining if keys have been picked up, etc. on map refresh.
As for timing in the game. I've implemented two different timers in my "to-be-posted" version,
one timer for the hero, and one for the baddie so I can reduce the speed of the baddie. I'm
still fighting the brick timer.
@OBC,
As far as storing the open blocks, are you storing an array of 'open' blocks, with their screen position as the value? Also, I would think each 'open brick' is going to need it's own 'timer' (delay), correct?
I would think you could do something like the following (note: code is untested--just me thinking off the cuff) [noparse][[/noparse]Edit:] Silly formatting!· Have tried to fix this twice.· Hopefully now it is what I intended --trodoss
CON
OPEN_BRICK_ACTIVE = 0
OPEN_BRICK_X = 1
OPEN_BRICK_Y = 2
OPEN_BRICK_DELAY= 3
OPEN_BRICK_LEN = 4
'max number of open bricks possible
OPEN_BRICK_MAX = 6
'pre-defined brick delay
OPEN_BRICK_DELAY_VALUE = 10
VAR
'store brick data
byte openbrickdata[noparse][[/noparse]OPEN_BRICK_LEN * OPEN_BRICK_MAX]
PUB Main
'...in your main loop
repeat
'... when an open brick is added -- for example
AddOpenBrick(10,11)
'... processing for all the open bricks
HandleOpenBricks
PUB AddOpenBrick (x_pos, y_pos) | ptr, break, i
'find first available open brick position, or we have gone all the way through the array
break := false
i :=0
repeat until break
if (i == OPEN_BRICK_MAX)
break := true
else
ptr := @openbrickdata + (i * OPEN_BRICK_LEN)
if (byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_ACTIVE] == false)
byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_ACTIVE] := true
byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_X] := x_pos
byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_Y] := y_pos
byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_DEALAY] := OPEN_BRICK_DELAY_VALUE
'draw the open brick (meaning put a space instead of where the brick should be)
text.pokechar(byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_X], byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_Y], black, 32)
break := true
i++
PUB RemoveOpenBrick(brick_ptr) | ptr, i
ptr := @openbrickdata + (brick_ptr * OPEN_BRICK_LEN)
're-draw the brick (if you are not redrawing the entire screen every time)
text.pokechar(byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_X], byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_Y], red, 43)
'set all of the values to zero
byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_ACTIVE] := false
byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_X] := 0
byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_Y] := 0
byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_DELAY] := 0
'bubble up any of the open bricks below this one in the array
repeat i from brick_ptr to OPEN_BRICK_MAX-1
if (byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_ACTIVE])
byte[noparse][[/noparse]ptr - OPEN_BRICK_LEN][noparse][[/noparse]OPEN_BRICK_ACTIVE] := byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_ACTIVE]
byte[noparse][[/noparse]ptr - OPEN_BRICK_LEN][noparse][[/noparse]OPEN_BRICK_X] := byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_X]
byte[noparse][[/noparse]ptr - OPEN_BRICK_LEN][noparse][[/noparse]OPEN_BRICK_Y] := byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_Y]
byte[noparse][[/noparse]ptr - OPEN_BRICK_LEN][noparse][[/noparse]OPEN_BRICK_DELAY] := byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_DELAY]
ptr+= OPEN_BRICK_LEN
PUB HandleOpenBricks | ptr
ptr := @openbrickdata
repeat i from 0 to OPEN_BRICK_MAX-1
if (byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_ACTIVE])
byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_DELAY]--
if (byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_DELAY] < 1)
RemoveOpenBrick(i)
[noparse][[/noparse]Edit:] I know it looks like I am on 'struct's like a broken record, but I think in terms of 'objects'·and structured data.··If·that is not the way you want to do it, or it seems like this is 'way out there' then do it the way you like/understand.· It is all about you enjoying what you are doing regardless of how you choose to do it.· If it runs, it runs...and that is all that really matters when you are coding for fun.
Post Edited (trodoss) : 11/14/2008 11:12:49 PM GMT
@OBC, I saw you mentioned '...on your next project' [noparse];)[/noparse] Excellent! I think will be a long time before either of us catches up with Baggers as far as games released. And--you have a 'head start' on me already :P
As for catching up with me, it's only cos I've been doing it as my job for the last 23 years that I can knock them out so quickly [noparse]:)[/noparse]
Definately keep going as long as you still enjoy it! Every new game on a Propeller-based system makes it that much more attractive of a platform. My oldest son *loves* playing the Hydra games (almost as much as his shiny new Wii).
Don't worry trodoss, I will, I'm just finishing a split screen function and Scroll helper for PropGFX as it WILL be final code on Sunday, as Coley will be making first new batch on Sunday, and then they'll start rolling, and I can get back onto doing games [noparse]:)[/noparse]
glad your eldest enjoys the games, and I hope you still do too lol
Baggers said...
As for catching up with me, it's only cos I've been doing it as my job for the last 23 years that I can knock them out so quickly [noparse]:)[/noparse]
I have been coding business apps for about 15 years now, so even there·I would say I am behind your experience [noparse]:)[/noparse]· Well, that is unless you have never had to code on an AS/400...
[noparse][[/noparse]Edit:] Apologies again, OBC...rambling on again on your thread <sigh!> I will try to keep on topic [noparse];)[/noparse]
@OBC,
IF you do think that you will be using something like the 'struct' code for the open bricks, I have a version of 'bubbling' up empty records using BYTEMOVE and LOOKDOWNZ that is likely going to be more efficient as I am working on a routine to handle something similar. I can definately see I have more to learn about using Spin [noparse];)[/noparse]
Re: How-To -- Do not mistake my inexperience at game-writing·for Bagger's wisdom [noparse];)[/noparse]· I am just passing along what I have found, and hopefully some/most is useful.· It is his industry after all [noparse];)[/noparse] The code I write for a living would *not* excite you.
Re: Ubuntu --I have had all sorts of interesting problems with Ubuntu·and certian hardware (USB and DB9 based mostly).· Things were flaky with Fiesty Fawn, and then only got worse when I installed Gutsy Gibbon.· Hopefully by now the issues I was running into on laptop hardware have been resolved.· I have·since started using·SUSE though, and have had a little more success.
[noparse][[/noparse]Edit:] Looking foreward to your updated game, BTW [noparse];)[/noparse]
Finally got my test files onto the SD.. (Thanks to Raymond)
I've updated my final version of LOADRUNNER for a while.
I'm to the point where I will completely rewrite this when I revisit it. [noparse]:)[/noparse]
I've got some ideas for incorporating what I've learned from this first
game writing experience into my next game.
(I *might* even try a driving sim using this engine. <GRIN>)
Hopefully the game creation discussion continues, I'm really learning here.
I desided to throw down and try out Loadrunner (I went to try it out before but it didn't work, didn't know it needed an SD card, oops). I don't have the SD cart for the Hydra so I did some modifcation to have it run on the Hybrid. One thing to note joypad mappings are different. They both use the same pins, but bit values are different.
I also modified it to use one button or two. Since the Hybrid uses the Atari style joysticks with one button, I modified it to so you can push the button and hold left or right to dig. Also made it so the button on joy 2 will reset the level and up on joy 2 will skip to a new level. And fixed a bug where if you go past how ever many levels you specify as max, it will go back to level·1 (instead of loading empty levels).
Anyway I am done stepping on your toes on this, but I hope you continue it on. And if you are looking for a new graphics driver that supports sprites, take a look at this. http://forums.parallax.com/showthread.php?p=737400
I think I found a bug though...
If you land on top of the bad guy, you seem to be stuck...
The bad guy won't move and you cannot move either to left or right...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Living on the planet Earth might be expensive but it includes a free trip around the sun every year...
Experience level:
[noparse][[/noparse] ] Let's connect the motor to pin 1, it's a 6V motor so it should be fine.
[noparse][[/noparse] ] OK, I got my resistors hooked up with the LEDs.
[noparse][[/noparse]X] I got the Motor hooked up with the H-bridge and the 555 is supplying the PWM.
[noparse][[/noparse] ] Now, if I can only program the BOE-BOT to interface with he Flux Capacitor.
[noparse][[/noparse] ] I dream in SX28 assembler...
Comments
I'd like a way to keep track of an object's given X,Y using a single variable.
(There has got to be a way to do this mathematically.)
Something along the lines of DATA1=X*Y which could be reversed to
determine X & Y in a screen of 20x23?
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
Again, no expert [noparse];)[/noparse] but I would think that since you know you have a 20x23 display, that you have 460 positions.
to calculate your x and y as one number, it would be:
position := (x * 20) + y
position := x + (y * 23)
to get back your x and y from the number (I think) woud be:
position_y := position // 20
position_x := (position - position_y) / 20
position_x := position // 23
position_y := (position - position_x) / 23
[noparse][[/noparse]Edit:] I was thinking backwards the first time
...that is assuming that the modulus operator // works like % in a language like C [noparse][[/noparse]Edit:]I will do some research on this later unless someone knows offhand
Post Edited (trodoss) : 11/14/2008 12:06:07 AM GMT
Since you know you will have more more than one enemy, each of which will have an x and y position (and possibly what direction are they moving in, are they alive/visible or dead/invisible--not being drawn, and how many gems have they stolen), if you have a single struct that describes your 'baddie' the easier it will be to manage.
The same could apply for your 'drillable blocks' (an individual counter for how long they will stay drilled maybe, as well as their x and y position).
If you need concrete examples, let me know.
--trodoss
I've implemented your character move stuff in the next release of Loadrunner (to-be-posted)
I've discovered that I need to do some serious work on timers now. The animation looks almost spot-on now.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
I was going to put don't use a value like 23, use something more computer friendly [noparse];)[/noparse] like 32
that way, positionx would be just position&31 and positiony would be position>>5 ( as >>5 is faster than /32 )
however, since your total value would be more than 256, it uses two bytes anyway.
So why not have one byte each [noparse]:D[/noparse] then you don't need to do any division
so your struct would be something like
alive = 0
positionx = 1
positiony = 2
action = 3
gemsstolen = 4
etc.
[noparse]:)[/noparse]
edit:
and position would be...
if your screen is 32·bytes wide
· position := scrbase + byte[noparse][[/noparse]badptr][noparse][[/noparse]positiony] << 5 + byte[noparse][[/noparse]badptr][noparse][[/noparse]positionx]
'···············=···· base·· +··· y * 32··· + x
if your screen is 32·words wide
· position := scrbase + ( byte[noparse][[/noparse]badptr][noparse][[/noparse]positiony] << 5 + byte[noparse][[/noparse]badptr][noparse][[/noparse]positionx] ) << 1
'···············=···· base·· +···( y * 32· + x·) * 2
if your screen is·40·bytes wide
· position := scrbase +·( byte[noparse][[/noparse]badptr][noparse][[/noparse]positiony] << 5·) + ( byte[noparse][[/noparse]badptr][noparse][[/noparse]positiony] <<·3 )·+ byte[noparse][[/noparse]badptr][noparse][[/noparse]positionx]
'···············=···· base·· +··(· y * 32 )··+ ( y * 8·) + x
'·············· =···· base·· +··y * 40 + x
if your screen is·40·words wide
· position := scrbase + ( ( byte[noparse][[/noparse]badptr][noparse][[/noparse]positiony] << 5 ) + ( byte[noparse][[/noparse]badptr][noparse][[/noparse]positiony] <<·3 )·+ byte[noparse][[/noparse]badptr][noparse][[/noparse]positionx] ) << 1
'···············=···· base·· +··( ( y * 32 )··+ ( y * 8·) + x ) *2
'·············· =···· base·· +··( y * 40 + x ) * 2
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
Post Edited (Baggers) : 11/14/2008 9:15:23 AM GMT
Thanks again!· I had·forgotten that Spin had bitwise shift operators, and that would indeed be faster.·
OBC,·are you using this·to calculate screen/map position, or are you trying to save variable space?
[noparse][[/noparse]Definately take with a grain of salt...] My recommendation would be to not sacrafice future 'readablitity' (when you have not·looked at the code in weeks/months and find a bug) by trying to 'pack' too much.· I have been guilty of that too many times and have been forced at that point to rewrite the code just to figure out what is causing the problem.
As far as· timing, make use of counters.· If you have a structure that represents the 'baddies,' certianly you could·add·in a counter to handle·that baddie's relative 'speed'·(how many cycles of 'delay' they have·in relation·to other things).· When that counter reaches their delay, then reset it.· That way, everything operates on a single 'clock,' but each individual object you are animating can be faster/slower than others, and appear to have their own 'virtual' clock in your game loop.··
[noparse][[/noparse]Edit:] Also, when something moves off the screen or dies, definately have (as Baggers has in his example) a variable that represents wether or not it is alive/visible.· That way you can check with an IF... before you try to animate/draw·the object, freeing up time otherwise dedicated to processing that object.
Pretty much, Baggers (brilliant, as always [noparse];)[/noparse] )·had already put those concepts in the struct code above, I just wanted to make sure (if you didn't already know) *why* he was putting things in the structure example he was showing.
Post Edited (trodoss) : 11/14/2008 3:37:00 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
from the original map. Having X & Y in one variable makes it easier to store the data.
I will probably not implement this until I do a complete re-write down the road, but I'm sure I'll want
the ability for the next project. Determining if keys have been picked up, etc. on map refresh.
As for timing in the game. I've implemented two different timers in my "to-be-posted" version,
one timer for the hero, and one for the baddie so I can reduce the speed of the baddie. I'm
still fighting the brick timer.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
Here is an example that I wrote over my lunch hour of using a struct with each 'baddie' having their own timer.
You will see a 'turtle race' at the bottom of the screen, with each of the turtles moving at different speeds.
I thought it might illustrate both what Baggers was showing with the struct, and what I was trying to explain with the timer.
--trodoss
As far as storing the open blocks, are you storing an array of 'open' blocks, with their screen position as the value? Also, I would think each 'open brick' is going to need it's own 'timer' (delay), correct?
I would think you could do something like the following (note: code is untested--just me thinking off the cuff) [noparse][[/noparse]Edit:] Silly formatting!· Have tried to fix this twice.· Hopefully now it is what I intended --trodoss
CON OPEN_BRICK_ACTIVE = 0 OPEN_BRICK_X = 1 OPEN_BRICK_Y = 2 OPEN_BRICK_DELAY= 3 OPEN_BRICK_LEN = 4 'max number of open bricks possible OPEN_BRICK_MAX = 6 'pre-defined brick delay OPEN_BRICK_DELAY_VALUE = 10 VAR 'store brick data byte openbrickdata[noparse][[/noparse]OPEN_BRICK_LEN * OPEN_BRICK_MAX] PUB Main '...in your main loop repeat '... when an open brick is added -- for example AddOpenBrick(10,11) '... processing for all the open bricks HandleOpenBricks PUB AddOpenBrick (x_pos, y_pos) | ptr, break, i 'find first available open brick position, or we have gone all the way through the array break := false i :=0 repeat until break if (i == OPEN_BRICK_MAX) break := true else ptr := @openbrickdata + (i * OPEN_BRICK_LEN) if (byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_ACTIVE] == false) byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_ACTIVE] := true byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_X] := x_pos byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_Y] := y_pos byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_DEALAY] := OPEN_BRICK_DELAY_VALUE 'draw the open brick (meaning put a space instead of where the brick should be) text.pokechar(byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_X], byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_Y], black, 32) break := true i++ PUB RemoveOpenBrick(brick_ptr) | ptr, i ptr := @openbrickdata + (brick_ptr * OPEN_BRICK_LEN) 're-draw the brick (if you are not redrawing the entire screen every time) text.pokechar(byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_X], byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_Y], red, 43) 'set all of the values to zero byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_ACTIVE] := false byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_X] := 0 byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_Y] := 0 byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_DELAY] := 0 'bubble up any of the open bricks below this one in the array repeat i from brick_ptr to OPEN_BRICK_MAX-1 if (byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_ACTIVE]) byte[noparse][[/noparse]ptr - OPEN_BRICK_LEN][noparse][[/noparse]OPEN_BRICK_ACTIVE] := byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_ACTIVE] byte[noparse][[/noparse]ptr - OPEN_BRICK_LEN][noparse][[/noparse]OPEN_BRICK_X] := byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_X] byte[noparse][[/noparse]ptr - OPEN_BRICK_LEN][noparse][[/noparse]OPEN_BRICK_Y] := byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_Y] byte[noparse][[/noparse]ptr - OPEN_BRICK_LEN][noparse][[/noparse]OPEN_BRICK_DELAY] := byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_DELAY] ptr+= OPEN_BRICK_LEN PUB HandleOpenBricks | ptr ptr := @openbrickdata repeat i from 0 to OPEN_BRICK_MAX-1 if (byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_ACTIVE]) byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_DELAY]-- if (byte[noparse][[/noparse]ptr][noparse][[/noparse]OPEN_BRICK_DELAY] < 1) RemoveOpenBrick(i)[noparse][[/noparse]Edit:] I know it looks like I am on 'struct's like a broken record, but I think in terms of 'objects'·and structured data.· ·If·that is not the way you want to do it, or it seems like this is 'way out there' then do it the way you like/understand.· It is all about you enjoying what you are doing regardless of how you choose to do it.· If it runs, it runs...and that is all that really matters when you are coding for fun.
Post Edited (trodoss) : 11/14/2008 11:12:49 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
glad your eldest enjoys the games, and I hope you still do too lol
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
[noparse][[/noparse]Edit:] Apologies again, OBC...rambling on again on your thread <sigh!> I will try to keep on topic [noparse];)[/noparse]
Post Edited (trodoss) : 11/15/2008 6:43:42 AM GMT
IF you do think that you will be using something like the 'struct' code for the open bricks, I have a version of 'bubbling' up empty records using BYTEMOVE and LOOKDOWNZ that is likely going to be more efficient as I am working on a routine to handle something similar. I can definately see I have more to learn about using Spin [noparse];)[/noparse]
This thread is quickly turning into a game writing how-to/discussion. Awesome.
I would have already posted my Loadrunner update, but I've slammed a wall of not
being able to read/write my SD cards under Ubuntu.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
Re: How-To -- Do not mistake my inexperience at game-writing·for Bagger's wisdom [noparse];)[/noparse]· I am just passing along what I have found, and hopefully some/most is useful.· It is his industry after all [noparse];)[/noparse] The code I write for a living would *not* excite you.
Re: Ubuntu --I have had all sorts of interesting problems with Ubuntu·and certian hardware (USB and DB9 based mostly).· Things were flaky with Fiesty Fawn, and then only got worse when I installed Gutsy Gibbon.· Hopefully by now the issues I was running into on laptop hardware have been resolved.· I have·since started using·SUSE though, and have had a little more success.
[noparse][[/noparse]Edit:] Looking foreward to your updated game, BTW [noparse];)[/noparse]
Post Edited (trodoss) : 11/15/2008 6:24:01 PM GMT
I've updated my final version of LOADRUNNER for a while.
I'm to the point where I will completely rewrite this when I revisit it. [noparse]:)[/noparse]
I've got some ideas for incorporating what I've learned from this first
game writing experience into my next game.
(I *might* even try a driving sim using this engine. <GRIN>)
Hopefully the game creation discussion continues, I'm really learning here.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
· ''Hybrid Joy settings
· NES0_RIGHT··· = %00000000_00001000
· NES0_LEFT····· = %00000000_00000100
· NES0_DOWN····= %00000000_00000010
· NES0_UP······· ·= %00000000_00000001
· NES0_START··· = %00000000_00000000
· NES0_SELECT·· = %00000000_00000000
· NES0_B········· ·= %00000000_00100000
· NES0_A·········· = %00000000_10000000
I also modified it to use one button or two. Since the Hybrid uses the Atari style joysticks with one button, I modified it to so you can push the button and hold left or right to dig. Also made it so the button on joy 2 will reset the level and up on joy 2 will skip to a new level. And fixed a bug where if you go past how ever many levels you specify as max, it will go back to level·1 (instead of loading empty levels).
Anyway I am done stepping on your toes on this, but I hope you continue it on. And if you are looking for a new graphics driver that supports sprites, take a look at this. http://forums.parallax.com/showthread.php?p=737400
Post Edited (JT Cook) : 11/21/2008 7:42:28 PM GMT
Toes do not feel stepped on, glad to see some interest in the program.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
I think I found a bug though...
If you land on top of the bad guy, you seem to be stuck...
The bad guy won't move and you cannot move either to left or right...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Living on the planet Earth might be expensive but it includes a free trip around the sun every year...
Experience level:
[noparse][[/noparse] ] Let's connect the motor to pin 1, it's a 6V motor so it should be fine.
[noparse][[/noparse] ] OK, I got my resistors hooked up with the LEDs.
[noparse][[/noparse]X] I got the Motor hooked up with the H-bridge and the 555 is supplying the PWM.
[noparse][[/noparse] ] Now, if I can only program the BOE-BOT to interface with he Flux Capacitor.
[noparse][[/noparse] ] I dream in SX28 assembler...
/Bamse