[TI-Z80 APP] A puzzle collection games pack
Moderator: MaxCoderz Staff
- driesguldolf
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
Okay, I'm back...
As I predicted I didn't had the time to do much, I worked out the ballsim theory a little bit (and it is queued for now until I get the visual basic version working)
If I want to code properly I need long, non interrupted time blocks (wich I didn't have), so instead I made a level editor (blox) for the computer...
I hope I have more time from now on.
hmmm if you read this you get the intention those 2 weeks in the south France (the moutains, dunno its name in English) werent that great, Actually they were great! They have some beautifully towns there, also huge moutains, and superb food!
Anyway, vacation is over let's get back to work now...
As I predicted I didn't had the time to do much, I worked out the ballsim theory a little bit (and it is queued for now until I get the visual basic version working)
If I want to code properly I need long, non interrupted time blocks (wich I didn't have), so instead I made a level editor (blox) for the computer...
I hope I have more time from now on.
hmmm if you read this you get the intention those 2 weeks in the south France (the moutains, dunno its name in English) werent that great, Actually they were great! They have some beautifully towns there, also huge moutains, and superb food!
Anyway, vacation is over let's get back to work now...
- driesguldolf
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
OK, time for an update.
I'm kinda busy (this is not how I imagined my vacation would be...) anyway, the main system works,
I'm currently busy with Blox: made a level editor, the basics of the engine are almost running, here are some screenies to get started: (this time they should be solvable, usual rules apply (look a few posts back):
Possible level1:
Train in the standard game mechanics:
Possible level2:
Water and switch training:
Possivle level3:
A little bit more complex puzzle to confirm skills learned in the first 2 levels:
Possilbe level4:
Yay, elevator training:
any comments? graphics ideas? gameplay ideas?
EDIT: changed the pngs into jpgs, should load faster (MUCH faster size shrinked with 1600%)
I'm kinda busy (this is not how I imagined my vacation would be...) anyway, the main system works,
I'm currently busy with Blox: made a level editor, the basics of the engine are almost running, here are some screenies to get started: (this time they should be solvable, usual rules apply (look a few posts back):
Possible level1:
Train in the standard game mechanics:
Possible level2:
Water and switch training:
Possivle level3:
A little bit more complex puzzle to confirm skills learned in the first 2 levels:
Possilbe level4:
Yay, elevator training:
any comments? graphics ideas? gameplay ideas?
EDIT: changed the pngs into jpgs, should load faster (MUCH faster size shrinked with 1600%)
- driesguldolf
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
I'm finally working on this project again (I just made the step to the university, that's the reason for a lack of updates)!
Currently working on XBall, aka Jezzball, (for the 3rd time ) but I think I got it right now
This screenshot shows random spawning (without balls getting stuck into each other), drawing game elements, variable ball speeds and cursor movement.
Todo: finish collision detection, table splitting and a nice gui.
Did I mention it chooses when to update the screen (capped at 30fps) depending on how busy it is?
Currently working on XBall, aka Jezzball, (for the 3rd time ) but I think I got it right now
This screenshot shows random spawning (without balls getting stuck into each other), drawing game elements, variable ball speeds and cursor movement.
Todo: finish collision detection, table splitting and a nice gui.
Did I mention it chooses when to update the screen (capped at 30fps) depending on how busy it is?
- driesguldolf
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
* Does a spit take *
Somebody's doing ASM? Somebody's doing?...
* Coughs a while *
Somebody's doing ASM? Somebody's doing?...
* Coughs a while *
My diet consists of nails, code-stealers, and HP fans.
Projects:
Robot War [TI-82, TI Flash App]
Sonic the Hedgehog [Multiplatform]
Projects:
Robot War [TI-82, TI Flash App]
Sonic the Hedgehog [Multiplatform]
- driesguldolf
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
Ah crap, unexplainable bugs are appearing...
1) Balls are drawn randomly on the screen at times (I assume ball.move is called with ix not point to a ball struct)
2) My calculations indicate that a ti83+ must be perfectly capable of running the game with 15 balls. But it doesn't...
Meh, I'll figure it out...
1) Balls are drawn randomly on the screen at times (I assume ball.move is called with ix not point to a ball struct)
2) My calculations indicate that a ti83+ must be perfectly capable of running the game with 15 balls. But it doesn't...
Meh, I'll figure it out...
Yup. Sounds like your basic structural problem. Could be a ld bearing wall.
But really, I saw the same thing happen when using IY and IX. Only stuff would randomly shoot off in weird directions.
Anyway, this sort of reminds me of that game...was it Laser Mayhem? Crazy stuff to have on a calc.
But really, I saw the same thing happen when using IY and IX. Only stuff would randomly shoot off in weird directions.
Anyway, this sort of reminds me of that game...was it Laser Mayhem? Crazy stuff to have on a calc.
My diet consists of nails, code-stealers, and HP fans.
Projects:
Robot War [TI-82, TI Flash App]
Sonic the Hedgehog [Multiplatform]
Projects:
Robot War [TI-82, TI Flash App]
Sonic the Hedgehog [Multiplatform]
- driesguldolf
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
Don't be so negative
I've traced the problem back to the ball.move routine itself (Though I've absolutely no idea what it's doing wrong, the other thing could be memory corruption but pti doesn't have memory read/write watchpoints and flashdebugger is being annoying). Everything else is running correctly as I told it too.
I'll find it... Hopefully it's related to bug #2 (as listed above).
Here's a screenshot of the mess:
(balls with grey around them are moving, the others are... well I don't know what they're doing there)
Just to be sure, this is the way I calculated the overhead:
I hope this format makes it more readable
A single ball.move takes around 3,000-4,000cc (using pti's clock counter), we'll round that to 5,000cc.
Suppose 15 balls that move every 3 interrupts (108 Hz, it's the slowest speed), that's 36 pixels per second.
The overhead generated by moving the balls is:
15×108/3×5,000 = 2,700,000cc/s
But updating the lcd also takes a lot of time, currently it's fixed at an update per 3 interrupts (~36 fps), an update itself takes less then 60,000cc:
108/3×60,000 = 2,160,000cc/s
Everything else is at this moment peanuts compared to these two.
Thus per second we need 4,860,000cc/s but the ti83+ can handle 6,000,000cc/s so it can run it, especially since we gravely overestimated the number of cc's it actually takes to move a ball/ update the lcd.
Final note: Don't worry, balls aren't moved during the interrupt itself, but are queued, the next time the mainloop restarts all 'events' (moving a ball/ updating the lcd) are executed.
The problem is that the queue overflows a lot (it can hold 64 entries however) which indicates that the processor can't keep up. BUT we just calculated it should...
I've traced the problem back to the ball.move routine itself (Though I've absolutely no idea what it's doing wrong, the other thing could be memory corruption but pti doesn't have memory read/write watchpoints and flashdebugger is being annoying). Everything else is running correctly as I told it too.
I'll find it... Hopefully it's related to bug #2 (as listed above).
Here's a screenshot of the mess:
(balls with grey around them are moving, the others are... well I don't know what they're doing there)
Just to be sure, this is the way I calculated the overhead:
I hope this format makes it more readable
A single ball.move takes around 3,000-4,000cc (using pti's clock counter), we'll round that to 5,000cc.
Suppose 15 balls that move every 3 interrupts (108 Hz, it's the slowest speed), that's 36 pixels per second.
The overhead generated by moving the balls is:
15×108/3×5,000 = 2,700,000cc/s
But updating the lcd also takes a lot of time, currently it's fixed at an update per 3 interrupts (~36 fps), an update itself takes less then 60,000cc:
108/3×60,000 = 2,160,000cc/s
Everything else is at this moment peanuts compared to these two.
Thus per second we need 4,860,000cc/s but the ti83+ can handle 6,000,000cc/s so it can run it, especially since we gravely overestimated the number of cc's it actually takes to move a ball/ update the lcd.
Final note: Don't worry, balls aren't moved during the interrupt itself, but are queued, the next time the mainloop restarts all 'events' (moving a ball/ updating the lcd) are executed.
The problem is that the queue overflows a lot (it can hold 64 entries however) which indicates that the processor can't keep up. BUT we just calculated it should...
- driesguldolf
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
Just did my final exam (by which I mean my yearproject, the assistants (who evaluated the projects) literally said mine was the most impressive )
Btw, that bug is found (but not fixed). Apparently a ti83+ simply can't handle that much so I slowed down the balls.
Working on 'splitting' the 'table'.
(as in splitting -> that thing you use to split the game into multiple areas for the balls to bounce in and
table -> the data structure behind the areas.)
Btw, that bug is found (but not fixed). Apparently a ti83+ simply can't handle that much so I slowed down the balls.
Working on 'splitting' the 'table'.
(as in splitting -> that thing you use to split the game into multiple areas for the balls to bounce in and
table -> the data structure behind the areas.)
- driesguldolf
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
- driesguldolf
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
Anyway, consider the 'splitter' 3/5 done.
After that the engine itself is done (though I need to fix some stuff I ignored a while back) and I only need to turn it into a game. (adding scoring, next level, menu, etc.)
And instead of making all the games and releasing them in app form, what about releasing them seperately (as beta perhaps) for mirageos as well?