Jump to content

Ringman

Members
  • Content Count

    70
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Ringman

  • Rank
    Star Raider

Recent Profile Visitors

5,351 profile views
  1. Any word on this. I haven't really played around with this in a while, I've been really busy. However curiosity struck so I'm checking in.
  2. Thanks! I'll try to play around with it soon. @SeaGtGruff: Do you still plan on finishing your version, or would you rather me just work with the PAL version Thomas posted?
  3. Thanks for posting the older topic. I just read through that. So, as far as I understand this won't work on a 2600? Is that right? If that's the case, that's a real downer. I guess the only thing from there would be to disassemble the original binary. Then I could probably use Stella's debugger to figure things out from there. Thanks for the help so far, though. I noticed the subroutines too. It acts somewhat like a switch statement, right? I'm a little confused at how the SARA chip works, and how its being used here. It looks like its jumping to positions within the SARA chips memory to extract certain variable information. The player movement routines is of particular interest to me, and it looks like it uses a preset offset in the SARA chip + an offset for the player's vertical and horizontal positions, and loads that into the accumulator, does some addition and subtraction, then does it write that back to the SARA chip again? My best guess so far, is that the player position is simply incremented or decremented by 1. To make the player move faster, I should just increment it by an arbitrary value? Or should I be hunting down the main game loop and look for some form of refresh rate? If you don't know, that's cool too. This is my project after all, and I'll figure it out eventually even if I have to try messing with random stuff to do it. Thanks again.
  4. Awesome! Again, thanks guys. I'm slowly making my way through it and trying to figure out each component. It looks like there's lots of promise here.
  5. That would be extremely awesome, thanks. I'm just trying to modify the speed of the player. It looks like it will also modify the speed of the enemy judging by the code. This is is to finally finish an extremely old project I had started back years ago.
  6. I'm trying to assemble this source code for Dark Chambers: http://www.romhacking.net/documents/498/ Yet I'm a bit clueless on how the heck to assemble the files. I've tried using dasm, but I'm having no luck. I'm a total noob to 6502 assembly and dasm. The only assembly language I've had any real experience with up to this point has been MIPS, (noob assembly code, amiright?). The info on romhacking.net states: "Unknown what this code compiles with." So this may be a lost cause. Can anyone help me out here?
  7. I'd like to defend these sorts of games. If you add a larger number of commands to input during each sequence, then play the thing with a dance-pad, these type of games become much more enjoyable. Try playing the segacd "Power Rangers" game on a dance pad, and you'll see what I mean. Games like DDR and Guitar-Hero, are simply Dragon's Lair games set to music! And look how popular those games are.
  8. What about Dark Chambers??? One of my favorite 2-player coop games for the 2600.
  9. So I recently came across this screenie you posted in a search. I had been working on a java program for doing a 3d dungeon game, I was thinking along the lines of something like Dungeon Master , but I had been kicking around the idea of making it a "simulation" of a handheld lcd game (either real or fake). I'm very interested in the gameplay of this Spyro game and if you could possibly post some videos or a scan of the manual or some kind of description, I'd be very grateful. I'd like to see if this is fits the bill of the kind of program I'm looking to write. I already began working on the skeleton of the graphics handling (calculating relative coordinates based on the player's position, and orientation). So I'm not so far in that I can't go in a variety of directions, and this looks like it might have simple enough gameplay to test this thing out on, then allow me to move on with engine in a totally different direction if I wish. Thanks.
  10. Agreed. But, in the situation I had, the professor required that we use GL_SELECT in some way anyway, so I just used it for collision detection. The only issue with doing collision detection the old fashion way, is dealing with the map walls as well as the robots, every shot they make, the player his shot, and evil otto all testing on whether or not any one of them hit any other one. Call me lazy. Funny thing, is, apparently the idea behind using GL_SELECT for collision detection was such an ass backwards way of doing things, the teacher actually thinks I should write a paper on it, because its still considered "clever." So I guess I'll give it a try, but I didn't think it was all that unique of an idea, I figured the relationship between the two were quite obvious. Doing a paper for it and giving a little demo of it for my school's conference, is still good for a resume.
  11. Yeah the speed issue seems to be ATI driver related.
  12. Thanks! I appreciate the feedback. 1.Speed The speed thing is an issue that I was not aware of, as I haven't had any speed problems. I am new to using opengl and C so I still need to learn more about ways to save speed. However, I believe the speed problem is the cause of the selection function used for collision detection. Selection mode in opengl is a very powerful tool for determining placement of objects, but continuously using it to check for collision may be what's causing the slowdown. The one thing that doesn't make sense, however, is that the time() function used is supposed to keep the speed relatively constant. So it shouldn't go from massive slowdown to massive speed up. But, I'm not very familiar with how time() works just yet, so my "misuse" of it could be the speed problem as well. Or both. I need someone smarter then me to help me solve this one. EDIT: I found something that may shed some light on the speed issue: http://www.it.usyd.edu.au/~tapted/slow_glselect.html Depending on your graphics driver, it may be that gl_select mode isn't very compatible with newer graphics drivers. 2. Fairness I know about the robot shooting, instantaneously issue. This would be an easy fix, I just forgot about it because I was running out of time to finish this for class. The way to fix this is to make another value like "canShoot" and have it called "noShoot" and use it for robot lazer disabling in the menu and use "canShoot" as initially false, and make a counter that counts down to zero at the beginning before it allows the robots to shoot, unless of course noShoot is active, at which point it won't count down. I look into it. 3.Documentation Yep, you're absolutely right. Let's call it laziness. This was never meant to be released to the public initially so I didn't worry about it, there is plenty of comments in the code itself explaining alot of stuff. I also didn't know about the cygwin issue, which I have to make sure I tell my teacher that because he has had some compiling issues and this may be related. Thanks for pointing that out. I had eclipse auto compile this so I didn't need to worry about a make file. 5. Final If anyone has a mac and would like to give this thing a look at, let me know. Converting the code for Mac shouldn't be a problem, though I won't be able to compile it in a mac environment but I can make the code so that it "should compile" on a mac and the person can compile it themselves. Thanks, If I have time I'll try to address these issues, but we already got our next opengl assignment and it doesn't look like any improvements on this will be made in the near future. I currently work 14 hours a week, and have 3 comp sci courses a 200, 300 and 400 level course, plus a course in Photoshop that's easy but requires a lot of projects. Thanks again.
  13. Here it is: http://www.savefile.com/files/1840465 It's got some bugs: Evil Otto's speed isn't uniform (something wrong with my vector calculation) but he still functions, the robots' sprites seem to jump every now and then (I tried figuring out why but I couldn't, something to do with my glTranslate I suppose.) also the lazer bolts always show the horizontal bar sprite, (I meant to change that, but forgot, lol, it'd be an easy fix). Features missing: Lives, Score, Difficulty adjustment, sounds, bullet proof necktie. Right click for a "debug" menu that allows you to turn off robot shooting and evil Otto. Sorry if my code is sloppy, I never touched C or OpenGl befor this semsester. I did comment everything though, if you have any questions feel free to ask. I doubt I'll do any updates on this, at least not till the semester's over. Code layout: main.c - has the main loop obviously, and all the game running functions, plus the opengl ones. Has robot generation, collision detection, user control handling, handles the instructions in the game loop, player and map loading. entity.c - just has one function, the drawFrame function which is a for loop that reads off arrays of 1's and 0's and creates Vertices out of them to be drawn to the screen. player.c - handles player spawning, movment, shooting, dying and animation. robot.c - handles all the robot ai,shooting, movement, dying, and animation map.c - has the map generation, and door generation functions. lazer.c - handles lazer spawning, movment, and dying. * sprites.h - has all the sprites in them, obviously. They all use 2 dimensional arrays of 1's and 0's, but the robot sprites also have arrays of pointers to these arrays so he can iterate through them easily. source.h - just a crapload of includes and defines used by all of the classes. the other h files are self explanatory, robot and player do not have a header of their own they share the entity header. Anyway have fun playing around with the code, if you have any advice on how to improve some of my algorithms, let me know. Thanks. And if you use this as a base for anything, please give me credit.
  14. UPDATE: Evil Otto has been added, and tested. His movement algorithm seems a tad buggy because his speed varies alot, but he works and is very threatening. Since I'm coming to a close on this and still need to add menus, Im not going to be implementing robot difficulty changes or sounds or the bullet proof necktie. I'm not sure if I'll even have time for a score/lives system, but hopefully I will, depends on how much I need to do tomorrow night. The one thing I have to add is simple menu system, and I have to comment/organise, since that in itself will probably take a few hours and I don't get home tomorrow night till 7:00 I'll be pressed to finish this thing. Anyway, wish me luck. I'll post the code and exe when done.
×
×
  • Create New...