Omnimaga
Calculator Community => Other Calculators => Topic started by: {AP} on November 29, 2008, 11:25:22 pm
-
If you've been checking out my Game Info & Progress... you know I'm taking a short break from making Nyaar.
I decided I'll try out a simple action game.
Multiple moving objects was my main goal... and so far, I've psuedo-accomplished this.
So, what better test than dodgeball. From all sides.
So far, I have two directions, simple look, no real interface... but I've only been working on it for... maybe an hour and a half at most.
All BASIC and xLIB's 'drawsprite' function. (via Celtic III)
Here's a screenie of the progress so far. (kinda slow... really flickery)
(http://img140.imageshack.us/img140/4441/dbstartup0.gif)
(It's actually a bit faster than this... I used WabbitEmu's GIF capture for this one.)
Newest Screenie:
(http://img81.imageshack.us/img81/2470/apdodgeball2ef9.gif)
Download for latest version below.
-
How many objects are you hoping to be able to have without excessive slow down?
-
As many as I can without excessive slow-down. =D
I'm just going to keep pushing the limits until I can't anymore.
Also... I made it not flicker as much now. (random epiphany)
(http://img185.imageshack.us/img185/581/dbstart2hs0.gif)
-
What method are you using? Do all of the balls move per frame or are you iterating over them? All of my (poor) attempts at simultaneous movement go horribly horribly wrong with more than 4-5 objects. I'd be interested to see how fast you can get it. :)
[edit] I just thunk of something that might possibly work for those darn spiders in CC...
-
Each time the Repeat goes through, it moves all the balls in the direction they need.
(EDIT: I have 4 going now. One from each side of the screen. Only issue now is the slow response on key presses.)
(http://img151.imageshack.us/img151/2127/dbstart3ik2.gif)
-
quite fast so far. Just one thing tho, to erase the screen I would recommend against erasing everything if you are gonna have a HUD. Use rectangles to do so, that way you will not need to redraw the HUD every frame like i did in my old games, which slowed them down a lot x.x
-
No problem, the balls are XOR'd and the character is OR then XORd.
The reason the character is done that way is so it only erases during a keypress (getting rid of him flashing repeatedly).
Now that I think of it though, I'll try handling the balls the same way as the character... might be better.
-
well if you mean you xor every ball everytime to erase them this might slow the game downa bit too, especially when you will have many balls at once.
-
Well, how I draw them is by XORing them in (updating LCD) then XORing them out immediately after (don't update LCD).
It's how I did all of my menus. That way it looks like it's still there and is still there according to it's location, but I don't have to do any checks or anything to get things working.
Unexpected test result. It turns out that if you run at a ball straight on... you'll dodge it.
It has to do with the fact that the code checks if you and the ball occupy the same spot.
Example (ball = O; player = X):
O
X
O
X
X
O
X
O
Those are the exact locations after each run through of the game loop.
So they never actually occupy the same spot.
Though it still looks like you should have been hit.
I can't honestly think of a way to fix this either...
-
yeah I got this problem many times in my games before. I think Zelda Dark Link Quest TICF still does that. I am unsure about how to fix it without losing too much speed. Usually you would need to check for collision detection when the ball moves then re-check collision detection once again when you actually move
-
How about checking for collisions with the ball's current position and the player's previous position?
-
could simply make one check each time the player moves, and have a check for each time the balls move. Is your collision list or matrix based?
-
Actually, I have a variable based system.
The others seem like they'd take away a lot of extra space and probably speed too.
Though, I'm not positive.
Well, here's progress so far.
(http://img140.imageshack.us/img140/7397/apdodgeballgk2.gif)
Which brings me to my next weird problem.
As you can see in the second play through, after "Not a highscore" was displayed... it said 'Done' and finished which is weird because it's set up like this.
If (you didn't get a highscore)
Then
Disp "NOT A HIGHSCORE."
Pause
Else
(Processes highscore changing)
End
Goto (starting menu)
Lbl Q //Lbl for the 'quit' option from the menu
ClrHome
Output(1,1,"
As you can see... getting a highscore is cool.
But if you don't... it just Stops the program for some reason.
(EDIT: Found the problem... missing End.)
-
Does it go back to the main menu when you do get a high score?
I'm thinking you're probably missing an 'End' somewhere.
-
Yes.
Though, I fixed it so it does whether or not.
It was a missing End... >_<
Anyway... everything's cool now.
Still, wish I could make the keypresses more responsive.
No luck on optimizing that yet.
-
Are you using xLIB/Celtic III's getkey or the calculator's?
-
xLIB/Celtic III getkey (real(8))
If anyone wants to look at the code or try the game out... by all means go ahead.
It's attached to this post.
Any suggestions that anyone has are welcome.
I'm just proud to have gone this far in about 3-4 hours total (of actually programming and testing) on my own.
(EDIT: Game requires Celtic III, which is included in the ZIP.)
-
I normally hate to double post.
But, I'd like to say that this project is finished in my eyes.
(unless I get some more suggestions)
Just look below.
(http://img81.imageshack.us/img81/2470/apdodgeball2ef9.gif)
I made all balls come from the top.
Three difficulty levels which limit the area you can move around in and, in effect, makes the balls slightly faster.
Highscore system that manages all 3 difficulty scores individually.
New scoring system. Now, the closer you are to the top, the more points you get per dodge.
Fixed my old problem of running straight through the balls.
Download below. Enjoy. =D
(EDIT: I forgot the Pic... >_< Updated the attachment.
Also, you can easily have both Nyaar and Dodgeball on your calc at the same time.
Just make sure that the Pic1 from dodgeball is the one on your calc.)
-
oooh nice, reminds me a bit of Avalanche (old ASM game from Void Productions), nice job so far :)
-
I never knew how limited BASIC was when it came to being able to have multiple moving objects.
It makes a lot of game types seem impossible.
I'm glad I was able to do something decent with it.
It's actually kinda fun playing with.
Was more fun programming though.
I thought I'd have a longer break from Nyaar... but it looks like since this is done, I'll be going back to it.
Unless, I have a different idea for a game... but it's doubtful.
-
World Of Warcraft
err... not really, don't give up on Nyaar :)
I'll try to add the game to the download section when I get some time (since staff cannot add any screenshot to the server when adding new files)
-
Cool. =D
I'd work on WoW... but that'd require ASM knowledge... and frankly... I don't have time to learn. (or the patience)
Anyway, yeah... Nyaar. I'll begin working on it again.
I decided that animations (and BG) will be done last.
I should get the dungeon system out of the way first.
(EDIT: If you have any questions on what to put for the download information, just ask.)
-
true, asm requires a lot of dedication to learn and patience. Once you get it it gets easier to code some specific genres, but it's a PITA to code RPGs and you need the brain to learn ASM. I personally can't get the grasp of it and since my main genre is RPGs I doubt I would do much ASM games anyway
-
A little late, I know, but:
(http://www.freeimagehosting.net/uploads/6fa93ab8f4.gif)
I must have downloaded the ghost version or something...
-
Mhmm I wonder if this could be a Celtic/xLIB incompatibility... are you sure you got the latest version?
-
I think I did, and I made sure I was using Celtic III (I had both on my calc). Not sure though if I had the latest version or not.
-
Did you tried both? If it works with xLIB then it's an incompatibility with Celtic, else it might be something you did wrong while installing or a bug in the game, which would require {AP} to check out this topic
EDIT: I'm stalking {AP} now to make sure he does
j/k
-
I think it's a missing picture.
I had uploaded a version without it.
Here's a working version now though.
-
Alright thanks. Sorry to cause so much trouble -.-
-
Not a big deal.
-
ah, CelticIII. way to be an ass with your drawsprite function and the 11th pic variable -_-
-
x.x, I do hope when Iambian finishes CaDan that he continues working oN Celtic III. It would suck if Celtic died, since xLIB death was one of the reason why Celtic started x.x
But don't expect new updates before CaDan release, as from what he said he isn't planning to work on Celtic until his shooter is done
-
Pattrick told me he is still working on xLIB, and it will not be too much like the previous version...IDK what that means..
-
well I was talking about during the days Celtic II was released and III in the works. At that time xLIB was pretty much dead. Iambian was starting a new app, but we were not in favor of a competition with xLIB when Celtic barely even offered half of the xLIB function and the fact we would have needed to rewrite entire games if we wanted to make them Celtic III compatible, so Iambian decided to have all backwards compatibility with xLIB app and finally he decided by himself to also add Omnicalc Sprite( compatibility. However, lately tr1p1ea has been doing the same thing than Iambian in the early Celtic III days, he has started a totally new flash APP adding function to BASIC programmer, basically a new xLIB. The new app won't include functions from the old one. However we've been poking him around to convince him to chain the app with Celtic III. xLIB 2 would offer much more advanced stuff (maybe even Raycasting/Mode 7?), but it would be a shame if programmers wouldn't be even able to use the old functions from either Celtic III or xLIB 1 when xLIB 2 was installed. This is why I think they should be chained. Backward compatibility would be pretty much impossible, though, unless it was made a 32 KB flash app, because as much as Celtici III is much more optimized than xLIB to fit 2x more stuff into the same space, there are limits :P
-
I wonder if this used stuff like Celtic or xLIB scroll routines real(4? Sorry I forgot to add this to archives finally (added now), but when playing again, this is what I wondered. In xLIB xLIB Revolution and Super Mario Smash Dance, what I did is that I stored each kind of arrows and their position in lists before simfile starts, then during the game main loop, what I did is that I displayed the appropriate arrow at the bottom of screen and then the background image (which usually contained a HUD and/or other stuff). When doing the later I updated the LCD display. Then I immediately erased the background then did real(4 to scroll the screen 8 pixels up. The only time where the LCD was actually updated was when the background image was displayed. Doing this allowed me to have as many arrows on the screen as I wanted (8, in my case), and no matter how many there were on the screen, it still wouldn't slow things down. Also, each arrows locations were stored into a list so if such engine was adapted for something like your game or a racing game, collision detection wouldn't be that hard. The only problem is that if the projectiles locations are randomized, then game would take a ridiculous amount of time to load when starting up.