Reputation: 488 Architect
- Active Posts:
- 1,036 (1.72 per day)
- 24-April 12
- Profile Views:
- Last Active:
- Today, 08:29 PM
- OS Preference:
- Favorite Browser:
- Internet Explorer
- Favorite Processor:
- Favorite Gaming Platform:
- Your Car:
- Who Cares
- Dream Kudos:
- Expert In:
- Game Programming, XNA
Posts I've Made
Posted 18 Dec 2013Great job NemoKradXNA! I encourage everyone to take a look at that code; there was a lot of cool stuff there. And thanks for posting the code and sharing your code with everyone!
Posted 17 Dec 2013
Posted 17 Dec 2013I agree with what modi123_1 said. But I might add that there has to be a way to do 2D games in Java. I've heard of too many people doing that. So, there must be a library or access through OpenGL or DirectX or something to speed up the efficiency of Java (the problem is talking directly to the graphics card rather than Java itself). So, maybe look into Java as an option if you like Java.
Posted 15 Dec 2013I was hoping someone might give a better answer than the one I'm about to give, but I see no one has responded yet. I'm not sure what the best way is.
In general, I can say that you always want to keep your checks as simple as possible. What you don't want are millions of extremely complicated checks bogging your game down.
The first thing is to not check anything you don't have to. For example, with view frustum culling you eliminate anything that is not in view right off the top. I don't know that view frustum culling is what you want in this case, but my point is that anything that doesn't matter needs to be culled early before you spend a lot of time on it.
I think the goal is to get through the check in as few "CPU cycles" as possible. Or more plainly, make it as simple as possible. I might consider doing a queue of game objects that might overlap and that could collide in a similar manner. I might then pop the first object off the queue and check it against everything left in the queue for collision. This means that I'm only checking it once for collision, rather than checking the same object over and over again. I might process its collisions and then pop the next one off the queue.
I also might do a circle check on everything before doing a rectangle check. The circle check is faster and the rectangle check is not necessary unless the circle check detects a collision. Although, you are then doing two checks in cases where an actual collision occurs and that takes more CPU time. So, the circle check is only effective if it eliminates a lot of more complicated checking. Oriented bounding boxes are where it gets really expensive to check. That's where a circle check first really starts paying dividends. But you may not be using oriented bounding boxes.
For a tile based rogue-like, I would probably be using an array for collision detection as much as possible. I think that's going to outperform other checks by a pretty wide margin, if you can use it. A rogue-like is generally all tile based in the first place, so it lends itself well to an array collision check. And you can do more accurate collision checking after that check, much like doing the circle check first. I suppose though that. if you're allowing multiple objects to occupy the same tile, then you aren't really using an array anymore, but you could still check whether two objects are in the same tile before then doing a per-pixel check or something (in 2D).
Posted 14 Dec 2013I'm pretty much finished scoring the Pong Challenge and will be declaring the awards soon.
Unfortunately because of events in my life, I didn't get to finish my Pong game I was working on, but I've included a screen shot of the 3D Pong project I was working on and where it was at the time I stopped working on it about a month short of the deadline.
Basically, it was working as a racquetball game (no AI, just keep the ball on the court) and I had a bunch of stuff I was planning on working on it with.
The yellow reticle marks were needed because it was impossible to judge depth perception and predict where the ball was headed. And the paddle was transparent, so that you could put the camera behind it and still see everything on the court. I moved the camera around the side of the panel so that you can see its actually 3D, but its easiest to play when you keep the camera right behind the yellow paddle.
- Member Title:
- Here to help.
- Age Unknown
- Birthday Unknown
- Dallas, Texas, US of A, Planet Earth, Sol System, Milky Way Galaxy
- Rock music composition and performance, Grunge Music, Bebop (think Thelonios Monk), Swing (think Cab Calloway), Gaming, Astronomy, RPGs, Scuba, Sail Boats, Furniture Building, Cooking, Rocky Patel Cigars, Character Driven Dramas(like HBO's Deadwood), Story Telling (plot writing), Linguistics, Economics, Target Shooting, Electronics (don't know as much as I'd like to), all aspects of 3D game programing including music, physics, modeling, texturing, annimation, probability, AI, lighting, etc., Texas Holdem' Poker, Learning, Dogs, the love of my life (my pit bull), guns (especially 19th century black powder), putting make-up on ogres, etc.
- Programming Languages:
- C, C++, C#, Visual Basic, Java, Pascal, T-SQL, HTML, FoxPro, ASP.Net(very little), Assembler, Machine Code(conceptually anyway)
- Website URL: