MaxCoderz

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

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

Looks good. Very smooth!

o.o that looks really good!

Liazon wrote:o.o that looks really good!

Nah, that's just the beginning


But as you can see collision detection still needs work...

Oh btw, if it wasn't clear, there will only be ball&wall collision, no ball&ball.

* Does a spit take *

Somebody's doing ASM? Somebody's doing?...

* Coughs a while *

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

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.

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

looks good keep us posted...

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

sounds good, hope you get it working alright so we can see the progress.

Err this is going slower then expected... Also it's kinda boring but it has to be done

I also might be a bit addicted to tf2... shh.

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?