This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - chattahippie
Pages: 1 2 [3] 4 5 ... 25
31
« on: March 08, 2012, 10:27:40 pm »
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
32
« on: March 08, 2012, 10:20:56 pm »
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)
33
« on: March 08, 2012, 10:04:19 pm »
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  ). 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
34
« on: March 08, 2012, 09:58:27 pm »
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)
35
« on: March 08, 2012, 09:47:21 pm »
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.
36
« on: March 08, 2012, 09:21:44 pm »
How about checking to see if your sprites are within distance of each other
If {2nd sprite location} - {1st sprite's location} < 16 (or whatever number)
Do Stuff
End
Or
If {1st sprite location} + (sprite size) >= {2nd sprite location}
Would those work?
37
« on: March 08, 2012, 08:45:01 pm »
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  That's why the slime trail is there, it's one of my favorite parts of SMB
38
« on: March 08, 2012, 08:24:14 pm »
Time for a new update! In this update, I have created a new menu system! (And an intro with my name  ) 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 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 Make sure to have both prgmSLIME and prgmZSLIM unarchived As always, feel free to tell me what you think needs to be added/fixed
39
« on: March 04, 2012, 09:47:05 pm »
Find the DiagnosticsOn token in your catalog and run that on the homescreen. This will turn on diagnostics and display r and r^2. Why TI decided they would be off by default, and why they decided against putting the option in the MODE menu is beyond me.
In 2.55MP it is under Stat Diagnostics in the MODE menu
40
« on: March 04, 2012, 09:44:49 pm »
How would I go about doing that?
If you use Ti-Connect, when you compile the Axe program into an Assembly program (with the Axe app), the Asm program can be found under Protected Programs in the device explorer
41
« on: March 04, 2012, 06:16:15 pm »
me. <.<
I always imagined you more as having a face and arms
42
« on: March 01, 2012, 09:19:29 pm »
The lists are formated like {1,2,3,4,5} and you can use custom lists by using the little L (under the List menu.)
As for getKey, to find out which key is which, make something like this:
Repeat G=22
getKey->G
If G=/=0
Disp G
EndThis will return the numeric value of any key, and will end when you press [MODE]
43
« on: March 01, 2012, 09:16:32 pm »
You can try this:
Type 1 in homescreen, press enter, and check memory again.
Tried that, it doesn't fix it Still about 2000-2500 bytes lost per run 
44
« on: March 01, 2012, 08:35:30 pm »
I think I found a bug with this... it causes my RAM to steadily decrease I tried running both programs seperately, took out the "prgmNAME"Asm(E7EF7C4E) command, chose the same options on the menu (except no program was run from it), and no memory was lost  As you can see in the screenie, nothing was created, yet about 5000 bytes of memory disappeared (15000 at start to 10000 at finish)
45
« on: March 01, 2012, 07:26:14 pm »
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.
Pages: 1 2 [3] 4 5 ... 25
|
Show Posts