Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: chattahippie on February 12, 2012, 11:22:07 pm
-
To start this off, this is not the same as leafy's The Slime (http://ourl.ca/9613), but is a similar concept, and based off of the same idea as his.
The Slime is the game I have been working on, and is based off of Super Meat Boy. It is in 4 color greyscale, and really is my first real game in axe :D
I plan to include disappearing blocks, and anything else I think of later on.
For the controls, use the top row of buttons (Y= to Graph) as follows:
[Y=] - left
[Window] - right
[Trace] - Run / quick movement / confirm on level select
[Graph] - jump / confirm on main menu
They are odd controls, but I think they fit better for this game than normal ones :P
If you find any bugs, please tell me, I know they are numerous, and I would like to squash them all >:D
Also, the last level, level 4 from the level select screen, is just an area to play around with (no exit) :)
This is compiled for no-shell, btw, and will create another appvar, SAVE, so be warned, it will try to read old appvars named SAVE and go to junk ram levels :)
Now with a screenie!
-
Sounds neato :D
-
To import appvars don't you just need to drag them on the LCD like programs? ??? That's what I always do in my copies of Wabbitemu
-
To import appvars don't you just need to drag them on the LCD like programs? ??? That's what I always do in my copies of Wabbitemu
Didn't work for me D:
I will get one uploaded tonight, I have an idea of how to make it work ;)
EDIT: I managed to make a screenie with an outdated level, but it uses the same engine, so it shows it off well (I think :P )
-
I like how the slime leaves a slime trail. I also like the grayscale.
-
I like how the slime leaves a slime trail. I also like the grayscale.
Thanks! It took a while to get the trail working properly and the greyscale working well (lots of recompiles :P )
Anyways, here is a new update
This update introduces "spikes," basically death stuff, as well as a remake of all the levels (now 8 total)! ;D
Still, wabbit won't accept the appvar, so no screenie atm :(
I suggest either deleting the old appvSAVE, or just overwriting it with the included one
-
To import appvars don't you just need to drag them on the LCD like programs? ??? That's what I always do in my copies of Wabbitemu
Didn't work for me D:
I will get one uploaded tonight, I have an idea of how to make it work ;)
EDIT: I managed to make a screenie with an outdated level, but it uses the same engine, so it shows it off well (I think :P )
Ah ok I guess they broke that in newer WabbitEmu versions. Also this looks awesome, I didn't see the screenshot last time. L)
-
Ah ok I guess they broke that in newer WabbitEmu versions. Also this looks awesome, I didn't see the screenshot last time. L)
Thanks!
In that case, time to go download an old version :P
-
If they still keep older versions on Codeplex, try a build from early 2011 or something. It might still have the feature.
-
If they still keep older versions on Codeplex, try a build from early 2011 or something. It might still have the feature.
jacobly just informed me that the mac version is way outdated, so I think that is the problem D:
-
Oh you use mac, then it might be problematic. On Windows from time to time they broke that appvar feature, but during certain periods it actually worked fine.
-
I made another screenie (with some current levels >:D )
Now, the question is, what should I add to it next?
-
That looks really good...I don't get it, but it looks good.
-
That looks really good...I don't get it, but it looks good.
Thanks, but how can I make it more clear? I will include a tutorial eventually, if that will help.
-
Yeah the character moves a little too fast imo. I was just saying I don't know a thing about the game but the graphics are good, from first glance.
-
Yeah, the graphics immediately grabbed me. you should work a bit on the titlescreen tho
-
Yeah, the graphics immediately grabbed me. you should work a bit on the titlescreen tho
Okay, will do! Thanks for the advice!
-
Mainly make it more graphically like the game (atmosphere-like). This looks too... different.
-
Mmmm, I think it's okay given the limitations of the calculator itself. You should definitely adjust some of the physics in your game, though - you fall too fast. In the actual SMB you fall at a slightly floatier rate.
-
Mainly make it more graphically like the game (atmosphere-like). This looks too... different.
The current one is definitely temporary, I just threw it together so it wouldn't jump strait into the game.
I am currently moving the menu system to an entirely different program, so I will make it look more like the game :P
Yeah the character moves a little too fast imo. I was just saying I don't know a thing about the game but the graphics are good, from first glance.
Hmmm... I've slowed down the X-axis some, but I will slow down the jumping (it is really too fast ;D)
-
Hmm interesting choice of controls, the slime is a bit hard to control tho.
-
Woa really cool slime you got thar!
I really like how it changes the grayscale of all the things you touch ;D
-
Yeah, that's a cool effect you got from SMB. How exactly are you doing it?
-
Yeah, that's a cool effect you got from SMB. How exactly are you doing it?
Thanks!
When I check the collision, if the engine notices that I am on a wall, it draws a small rectangle on the back buffer then inverts it to avoid having ugly looking black dots at corners :P
And the collision is checked based on the direction you are moving, so it knows which side of the tile to draw the trail on
-
Ah, okay. I thought you were editing the tilemap somehow, but now I realize that wouldn't make sense because it doesn't actually change the tile, and also I'm sure you're not redrawing the screen every frame.
EDIT: Also, how are you doing the wall-jumping?
-
Ah, okay. I thought you were editing the tilemap somehow, but now I realize that wouldn't make sense because it doesn't actually change the tile, and also I'm sure you're not redrawing the screen every frame.
EDIT: Also, how are you doing the wall-jumping?
Just about the same way
The Y acceleration must be either zero or downward, and it checks to see if you are on a wall. If it is, you stick to the wall, falling slows, and it will allow a jump.
-
Time for a new update! :D
In this update, I have created a new menu system! (And an intro with my name ;D )
With the menu, I created a better level select! I am still working on making it faster/better, but it is much much better than the old one :)
Here are the controls:
[Y=] - Play
[Window] - Level Select
[Zoom] - Quit
[Clear] Quick escape :P
Use [Graph] to confirm
Also, I have used the routine DrDnar posted on running Axe programs from within other Axe programs to allow for Slime to be larger than it should be :P
Make sure to have both prgmSLIME and prgmZSLIM unarchived
As always, feel free to tell me what you think needs to be added/fixed :)
-
I like this game, but could you consider changing the controls?
-
Wow I really love the menu and how everything transitions in! Were you inspired by Super Meat Boy for this project? That's the first thing that came to my mind when I saw it...
-
I like this game, but could you consider changing the controls?
I tried to make it feel like a real game by putting the left/right on the left side of the calc,
but I can add more controls (d-pad and 2nd/Alpha) next time
Wow I really love the menu and how everything transitions in! Were you inspired by Super Meat Boy for this project? That's the first thing that came to my mind when I saw it...
Thanks!
Actually, this game is based off of SMB :D
That's why the slime trail is there, it's one of my favorite parts of SMB :P
-
Oh I just now saw that in the OP... I will definitely have to agree with you on the slime trail...
-
How did you get such good grayscale??
-
How did you get such good grayscale??
I am running the game at 15 MHz, which helps, and also use a total of two DispGraphrr commands (one was way to slow), but I had to slow it down with a Pause (about 10) to really get it good, as the double DispGraph made the greyscale update too fast. Honestly, it would be even better if I used interrupts, but I will mess with those later.
-
So is this a tile-map or pixel-perfect? Would making it pixel-perfect slow it down a lot?
-
So is this a tile-map or pixel-perfect? Would making it pixel-perfect slow it down a lot?
For the collision? It is a mixture. It checks to see if the tiles in a 2x2 grid surrounding the character are solid, and if they are, only checks pixels in the direction the character is accelerating
If it was completely pixel-perfect and constantly checked collision in every direction, it would be a lot slower than it is, and the greyscale would mess up more (like it does when you run into walls)
-
Well I am making a game, and right now it is pixel perfect. Basically right now it checks if above, below, left, and right of the player are solid, and saves it to variables. Another task (thread) checks those variables to see if it can move (The player only collides with the bottom left corner which stinks :P). Is there a better, more efficient way to do this? The grayscale is not as good as yours because of the time it takes to draw all the stuff and check pixels.
-
Well I am making a game, and right now it is pixel perfect. Basically right now it checks if above, below, left, and right of the player are solid, and saves it to variables. Another task (thread) checks those variables to see if it can move (The player only collides with the bottom left corner which stinks :P). Is there a better, more efficient way to do this? The grayscale is not as good as yours because of the time it takes to draw all the stuff and check pixels.
If you are using acceleration, you can improve it by only checking the ways your character is moving
Ex:
If you are going down and right, only check those two directions
That should speed it up some, if not a lot
-
I tried it, but I can't really tell if it helped or not. Is there any other way?
EDIT: But doesn't it always have to check down? Because it has to check if it collides?
EDIT2: Do you use buffers for your game?
-
If you also switched to a tilemap system, you can figure out whether or not to even check collision (if everything around you is transparent, no collision is needed, and therefore doesn't need to be tested for). Also, I suggest throwing an extra display routine in your program. Try to place a fair ways away from the other, but make sure the picture is still the same (as in nothing has moved)
-
???
I'm confused with your last 2 sentences. Extra display routine? fair ways away? Nothing moved in picture? Do you think you could maybe show some psuedo?
-
Sure, and I will explain further:
Extra display routine - update the screen more than once per loop of the engine
By a fair ways away, I mean make sure that there is lots of time between the updates, to better the effect
And by nothing moved, I mean no sprites have been erased from the screen
And here's my example:
Game loop start:
Update the screen with the current picture
Calculate movement
Calculate Collision
Update the screen again -- nothing has changed since the last screen update
Now change your sprites, and update the tilemap, etc.
Game loop end
-
But there are 2 threads, not one.
And also wouldn't it have to update the screen 3 times since it is 4 lvl grayscale?
-
But there are 2 threads, not one.
And also wouldn't it have to update the screen 3 times since it is 4 lvl grayscale?
Not necessarily - sometimes that will break the greyscale even further
Basically, the way to get it perfect is just to mess around with the number of screen updates and time between updates -- I spent an hour just playing with different places for the second screen update, how long the pause in between the updates should be, and just getting everything set up nicely
-
???
That doesn't make sense. Why would it only update twice if there are 4 colors? Shouldn't it update 3 times?? Because 4 level grayscale has 3 pictures.
-
???
That doesn't make sense. Why would it only update twice if there are 4 colors? Shouldn't it update 3 times?? Because 4 level grayscale has 3 pictures.
True, but if you updated three times per loop, it could look like nothing is happening at all if there is not a delay between the third and first update:
1st update: 001001001
2nd update:010010010
3rd update:100100100
1st update: 001001001
With two updates per loop, even if the second update is close to the 1st, it will always change every loop of the engine:
1st update: 001001001
2nd update:010010010
1st update: 100100100
It really just depends on how fast/slow your engine is... If you are still having problems, I would suggest making a new thread so that other people can help you, because I've seen people make 4 scale even better than me
-
4-level grayscale only uses 2 buffers, not 3.
-
But won't the grayscale start getting messed up if there is too much stuff in the coding section (collisions, enemies, etc)?
-
Yes it would but then he can remove the pause.
chattahippie, epic title screen is epic!
-
Pause? What pause?
-
Pause == delay
He has a delay with a value of 10 in the loop.
-
10? 10 milliseconds?
-
no its just a number.
In 6mHz mode, there go about 1700 pause loops in a second.
-
Oh, that seems more complicated than just waiting a certain amount of time.
EDIT: So chattahippie does that delay to slow down player movement?
-
Oh, that seems more complicated than just waiting a certain amount of time.
EDIT: So chattahippie does that delay to slow down player movement?
Yes, it slows down the entire game a little bit, but is unnoticeable due to the pause being so small
-
In your game do you use temporary buffers?
-
No, just the main front and back buffers (L6 and L3)
-
Hm, are you just Pt-Changing the character then?
-
Hm, are you just Pt-Changing the character then?
Yes, and it makes the game much faster, and also allowed me to make the trail
It only draws the tilemap when switching levels
-
How does it use pxl-test if the killing blocks are light gray?
-
How does it use pxl-test if the killing blocks are light gray?
Axe uses only two buffers, the main and the back buffer
When the main buffer is on, the pixel appears dark grey
When the back buffer is on, the pixel appears light grey
When they are both on, the pixel is black
But since there are only two buffers total, I check collision against the main buffer for actual collision
and I use the back buffer for death collisions
To get around black blocks killing the character (they also use the back buffer), I test outside the character sprite for main collision,
and inside the sprite for death collision (the player sprite resides only on the front buffer)
Hope that made sense :P
-
Aahhhh...
Yeah, that makes sense (mostly :P).
So in my game it first turns off the display refreshing. Then it draws the collision pixels, then checks the pixels and saves it to a variable. Then over that it draws the death pixels and checks them and saves them to a variable. Then it draws what you actually see. Then it turns back on the display refreshing.
EDIT: for some reason when I try to play your game it says "error: memory." It says that when I select a level and on wabbitemu it says that even if I just press play.
-
for some reason when I try to play your game it says "error: memory." It says that when I select a level and on wabbitemu it says that even if I just press play.
You should clear your memory first, and make sure SLIME and ZSLIM are in RAM, and also appvLEVELS should be archived
-
oh, ok.
So do you think what I do for my game is a good way for collision?
-
Yeah, sounds alright to me
But I would suggest only drawing the level when you start the stage,
and only checking pixels and drawing the character every frame
So,
At start of level - draw the entire level
Then,
Every frame - Check movement/death, Draw player, update screen, erase player
-
But, since it is grayscale, I have to be constantly updating the screen for all 3 frames.
-
But, since it is grayscale, I have to be constantly updating the screen for all 3 frames.
If you are using buffers, you don't have to. The buffer is solid data, but the screen only displays a fraction of that, in the appropriate greyscale
-
ha ha.....
Actually this is not for a calc game. :P
It is for an NXT game, so it doesn't do what the calc does w/buffers.
-
Looks nice :D
-
Who made the levels? Did you?
Oh, and are you a good spriter/level creator for pixel-by-pixel?
-
Who made the levels? Did you?
Oh, and are you a good spriter?
Yeah, I made the levels, and I'm an awful spriter (the character is just a rectangle with dot legs) :P
-
Oh, cool. Well are you a good level designer (pixel by pixel not tiled)?
-
Oh, cool. Well are you a good level designer (pixel by pixel not tiled)?
No, I usually tile everything
-
oh... ok.
-
Someone should make a walkthrough :P
Im stuck on one level D:
other than that, nice game Chatta :D
-
Someone should make a walkthrough :P
Im stuck on one level D:
other than that, nice game Chatta :D
Thanks! Which level, I can help