QUOTE (saubue @ Apr 20 2006, 01:44 AM) |
[removed]That was kinda rude, if he was asking for sprites that prbly because he wasnt able to draw them in the first place |
CODE | ||||||||||||||||||||||
ec1void miscFunction(short arg1) { Post by: Liazon on April 21, 2006, 09:07:00 am kalan: Basic is more like an interpretted languages, so trying to insert a native language within Basic code would require some kind of address change of some sort. iirc of course :D ![]() Post by: saubue on April 21, 2006, 09:23:00 am Post by: kalan_vod on April 21, 2006, 12:41:00 pm Post by: DJ Omnimaga on April 21, 2006, 01:36:00 pm Post by: Liazon on April 21, 2006, 05:22:00 pm btw, I didn't kill r/p/s. I just don't feel like searching for the bug rooted in the greyscale implementation after I've only finished about 6% of the game. Now that I know how to define a C structure, I think I'll make a structure to organize different character types and make the tile stuff easier. I'll have to fix the way I store data, but I'll eventually fix the greyscale sprites and finish the battle engine. @saubue: thanks. I hope C will be sufficient for a black and white game. Post by: saubue on April 22, 2006, 02:36:00 am
sufficient? You can do almost anything with TIGCC. However, if you might need some help, feel free to ask :) ![]() Post by: kalan_vod on April 22, 2006, 03:33:00 am ![]() ![]() Post by: Liazon on April 26, 2006, 02:21:00 pm ![]() ![]() From the top left going clockwise: 1. Standing still 2-3. Running 4. Sliding to halt 5. Jumping frame 6-7. Possible falling frames. I like #7 (the one on the left) personally. 8-10 Possible wall sliding frames. I personally like #10 (bottom left) the most. I'll have to use the other comp to experiment with animation frames in imageready. Just to see if I like the sprite sets. Any suggestions for the game or the sprites is welcome! I'll probably have more to add to the project description later. Post by: kalan_vod on April 26, 2006, 02:31:00 pm ![]() Post by: DJ Omnimaga on April 27, 2006, 01:20:00 am Post by: Spellshaper on April 27, 2006, 03:26:00 am ![]() Post by: kalan_vod on April 27, 2006, 04:01:00 am Post by: Liazon on April 27, 2006, 09:48:00 am Original Game: http://www.freeworldgroup.com/games2/gameindex/ngame.htm So I'm basically trying to port that onto 89 calcs. It will be black and white using 8x8 sprites and tiles. I don't know how many enemies and tiles from the original game I will be able to include, but I'll try my best. This and r/p/s are my first projects. Unlike the original game, N-Game 68k is not played on one screen. It will scroll and the maps will be larger than 12x20 tiles. What I want to do is to create a pause option that will allow you to pause and scroll around the whole map. As for dealing with enemies, like the homing drones, the snipers, the missles, and the like, I will add a feature called the N Sense. It'll be some for of indication that will tell you if you've been locked on by something, or if something is trying to target you. I don't know how well I can recreate the physics in the original game. It is really complex which is why I'm not sure if I can include tiles like the curved ones and the irregularly shaped ones. Post by: Liazon on April 27, 2006, 09:58:00 am 1.) Play the game 2.) Click on help, and then enemies (right) and read about them. Post by: kalan_vod on April 27, 2006, 10:14:00 am ![]() Post by: Liazon on April 30, 2006, 08:57:00 am ![]() More sprites!!!! I think I'm forgetting to do some. If someone sees a sprite I'm missing, please tell me. I need some advice from the C masters. Should I use rotation routines or should I just store all versions of the sprites? Which way is faster? I think I'd prefer the faster way, but I assume not using a rotation routine may make things difficult to organize. I'll really have to think about it. Caption: ROW 1: 1. Standing/facing right 2+3. Running right 4. Sliding right 5. Jumping right 6-7. Falling right 8. Wall sliding (wall on right) 9-11. Victory dance facing left ROW 2: 1. Standing/facing left 2+3. Running left 4. Sliding left 5. Jumping left 6-7. Falling left 8. Wall sliding (wall on left) 9-11. Victory dance facing right ROW 3: 1. mine 2. floorchaser 3. gauss turret 4. gauss turret aimer 5. homing turret 6-8. homing missiles 9. thwump ROW 4: 1-2. chaingun drone 3-6. laser drone 7-10. homing zap drone 11. zap drone ROW 5: 1. gold 2-4. standard door 5-7. access door 8-10. trap door 11. one-way platform ROW 6: 1. bounce block 2-5. launch pad 6. access panel 7-8. remote terminal 9-10. Exit Post by: kalan_vod on April 30, 2006, 09:49:00 am Post by: Spellshaper on April 30, 2006, 10:07:00 am *drool* *Spellshaper Post by: Liazon on April 30, 2006, 10:46:00 am
8x8 @SpellShaper: Maybe I'll port to 83+ later when I'm done with everything else. Of course, axcho on UTI could always use these sprites for his own ASM version. Post by: tenniskid493 on April 30, 2006, 11:10:00 am
We really need the worship smiley again, I'll see what I can do. This game looks sweet!!! :) ![]() Post by: DJ Omnimaga on April 30, 2006, 02:09:00 pm Post by: crzyrbl on April 30, 2006, 04:43:00 pm Post by: Spellshaper on April 30, 2006, 10:25:00 pm
kewl :) ![]() Post by: Alex on May 01, 2006, 07:28:00 am I voted no on the scrolling because for a game with such dynamic gameplay, the LCD would be too blury. I wish you all the best in your TI-89 pursuits! :) ![]() - Alex Post by: kalan_vod on May 01, 2006, 07:35:00 am ![]() Post by: Liazon on May 01, 2006, 08:04:00 am I'll have to see though. Lately I've just been brainstorming some math models for the movement, but it seems that every model has a considerable flaw. I'll have to work at it a bit. Post by: kalan_vod on May 01, 2006, 08:08:00 am Post by: DJ Omnimaga on May 02, 2006, 02:00:00 am Nice game Post by: kalan_vod on May 02, 2006, 05:06:00 am ![]() Post by: saubue on May 02, 2006, 07:33:00 am Post by: Liazon on May 02, 2006, 09:41:00 am To fix the blurriness problem brought up by Alex, Mathstuf recommended I use another buffer and then copy to the screen. My only concerns are speed. I've been planning to bloat the code a bit to push the speed just so that I can leave room to program the enemies exactly like in the original. So far, my plans for increasing speed include: 1.) Using low level key input (_rowread and _keytest) 2.) Not using rotation routines and storing a copy of all versions of the sprites. I don't know what else I could do, but I'll have to think about it a bit. I still find it a pitty I can't figure out a way to create curved tiles that would fit into my current math model (I like math :D ). Since N-game 68k and r/p/s (just a code name, read project description), are my first calc projects ever, I'll probably be switich between the two a lot, and just incorporating everything I learn as I go. Right now the main priority for N-Game is to set up a tiling system that works with the math model. then again, I might be overthinking everything. Bcherry seemed to have little problems creating the tile system in his metroid game. edit: Thank you very much for your opinions, especially from the expert C programmers like saubue and Alex. Post by: saubue on May 02, 2006, 10:19:00 am I think you can gain extra speed if you optimize the physics and the enemy behaviours as much as possible. You could also use a large map buffer for the map and modify ExtGraph's FastCopyScreen-routines to satisfy you needs (that's tricky, I've tried it once...). Anyway, I'm really looking forward to play a first beta! Post by: DJ Omnimaga on May 03, 2006, 01:40:00 am Post by: saubue on May 03, 2006, 02:15:00 am http://www.ticalc.org/archives/files/fileinfo/319/31951.html Post by: Liazon on May 05, 2006, 09:58:00 am I'm guessing, based on my busy schedule, this may not be completed until next year. Sorry! Right now its a combination of rl issues and time. There's a lot going on and I don't know if I'll be able to stay in the community much longer. If you guys hate me and don't want me right now, then I'll gladly take me leave. edit: if I suddenly disappear from the community for more than a month, please inform MC, UTI, and Revsoft that I might have left for good. Thank you! Post by: Radical Pi on May 05, 2006, 10:31:00 am Post by: Spellshaper on May 05, 2006, 10:32:00 am ![]() do whatever you think you could do best Post by: saubue on May 05, 2006, 12:13:00 pm ![]() Why don't you learn 68k Assembly? And the knowledge of C is very important if you want to code in the future, too. If you understand C, it's quite easy to migrate to C++, Java or PHP (as long as you are open for new stuff). At least, that's my experience. Post by: Alex on May 05, 2006, 12:36:00 pm - Alex Post by: Liazon on May 05, 2006, 01:10:00 pm atm though, I think I'm more worried about being able to stay active in the TI community. Post by: tifreak on May 05, 2006, 01:19:00 pm ^^ Try that, I believe I linked to an 68k asm page... :) ![]() Post by: spengo on May 05, 2006, 01:47:00 pm Post by: katmaster on May 13, 2006, 10:37:00 am ![]() Post by: DJ Omnimaga on May 14, 2006, 03:50:00 am ![]() Post by: kalan_vod on May 14, 2006, 11:52:00 am ![]() Post by: Liazon on May 15, 2006, 10:26:00 am Post by: kalan_vod on May 15, 2006, 01:42:00 pm Post by: Liazon on May 15, 2006, 02:36:00 pm also, I feel really overwhelmed because this is my first real project. I don't really know where to start coding. Thoughts brew in my head, such as, should I start with the tilemapper? should I make external level support available? should I work on the physics/character movement/key input engine first? when should I start puting enemies in the picture. I have no idea. Right now, it boils down to: should I start with movement first, or tilemap reading and writing? Post by: tenniskid493 on May 15, 2006, 03:05:00 pm ![]() Post by: Liazon on May 23, 2006, 12:14:00 pm ![]() lots of math to look at. I have to decide between two tiling methods. so far, I've got a player structure that has an x position and a y position. there's key counter too for each key. The hard part is to decide how to write a scheme for position change. I can't have the character change more than 2-3 pixels in position or the character might possible pass through enemies during the enemy collision. I was thinking that the key counter has a set limit so you can't hold the jump key and go up forever constantly accelerating/decelerating. and you can't run and get faster and faster. I think a seperate variable for additional vector effect is needed to allow for jump pads. Things that affect position: 1.) key press 2.) tile vector structure 3.) jump pads I think that's it. Jump pads is it's own curved equation in itself. So is key press. I don't want to add many calculations by adding together 2 different log/exp/quadratic equations. That's why I originally wanted to position change variables for both x and y. The first position change would affect the second, and the second put into an equation and modified by tile vectors would result in the final position change of 1-2 pixels per loop. I'm guessing that the speed of the 68k will make periods of not moving and moving seem like the sprite is slowing down. So moving 1 pixel every game loop is maximum speed. Idk how double buffering will affect the speed and the blurriness of the game. Oh ya, i forgot, to make everything work correctly, I'll have to make all the maps the same size. IIRC, the screen coordinates and map coordinates of tilemap engine and the screen itself are 0,0 at the top left, whereas most of my math right now is done with 0,0 at the bottom left. I'll have to change stuff to make it work. As for tiles, tiles have an associated tile vector structure. As long as the sprite is "on" that tile, the tile vector will change the position change. So a slope of 45 degrees might have a -1/-1, which will reduce the + whatever that the run key gives. The vertical and horizontal tiles will have INSANELY high vector changes, making it possible to run up a vertical wall if you're fast enough. (idk if i like this though) Calculation Processes: 1.) key input calculation 2.) tile vector calculation 3.) jump pad calculaton 4.) INSANE DEATH velocity detection. I hope the complexity of my design doesn't slow the game down. there's just so many variables in the problem I've kinda lost where to start and not screw up so badly i'm totally discouraged. Maybe it's about time to work on r/p/s again. :( ![]() btw, what does this mean? c1-->
ec2
Post by: Ranman on May 24, 2006, 11:02:00 am I finally looked at the N-Game on the internet. Wow!! O_O What a cool game! Great idea for a port! Let me know if you ever get stuck or need an idea. Post by: Spellshaper on May 24, 2006, 11:04:00 am
Yeah ^^ I'm still trying to beat all the episodes :ninja: ![]() same: In that case, maybe I'll use the 4x4 sprites that CDI made on MC. I just don't like that too much because of the tile mapping. Post by: Liazon on May 24, 2006, 02:31:00 pm
Same here Ranman: in that case I'll just use teh 4x4 sprites that CDI originally drew. I just don't like them as much. And the tilemapping. OR should I just break up maps into screen sized pieces and then just display the correct piece that the Ninja is in? really, the only bad thing about moving is that it affects precision movement and avoiding enemies by close margins. The bluriness would probably make it impossible to tell exactly how much room you have for error. Post by: DJ Omnimaga on May 24, 2006, 02:35:00 pm Post by: Liazon on May 31, 2006, 09:47:00 am I'm sorry I've failed you guys. Its a feeling that has persisted for awhile now, ever since I became staff. I won't abandon the project, but it might have to be pushed back. Looking at things now, I might have to revive DEM or r/p/s instead and work on something easier like those projects. I have to admit, I'm really struggling to find a place in the ti community. edit: oh ya, SilverCalcKnight on UTI plans to work on his own 89 basic version. Post by: Alex on May 31, 2006, 12:36:00 pm N-Game is a very ambitious and complex game to code. Keep in mind that the 'original' was "coded" in Flash, which has some very straight-forward routines for terrain detection, collision, etc. - coding it in C, where you have to do everything yourself is of course a very grueling task. - Alex Post by: Radical Pi on May 31, 2006, 01:06:00 pm There's nothing wrong with constantly looking back over tutorials, or even just writing ones for the practice. Not writing any code might be a problem eventually... Post by: DJ Omnimaga on May 31, 2006, 01:14:00 pm Post by: shadow on May 31, 2006, 01:50:00 pm (XD ![]() ![]() Post by: DJ Omnimaga on May 31, 2006, 02:30:00 pm
yeah unfortunately there is a lot of ppl (staff mostly) who arent feeling very well/are depressed on omnimaga :( ![]() QuoteBegin
This morning I reached 1000
Post by: spengo on May 31, 2006, 02:49:00 pm Post by: Radical Pi on June 01, 2006, 10:34:00 am ![]() Seriously though Liazon, what you probably need is practice. I've given in to it, and this small basic program made me feel special: c1-->
ec2
On the 83+ series it returns any missing part of a pythagorean triangle. Such a simple program, it is beautiful to me. This might be what you should be doing in Asm practice. Take the complicated ideas and simplify them like this. Post by: Liazon on June 04, 2006, 05:55:00 am Post by: Alex on June 04, 2006, 08:45:00 am - Alex Post by: threefingeredguy on June 04, 2006, 01:29:00 pm |