• Content count

  • Joined

  • Last visited

Community Reputation

361 Neutral

About Maxamor

  • Rank
  1.   Most large things start off small and grow large over time.         I like to think of the player and enemies as puppets, and the level is a stage -- without a puppet master they don't do much. I would put this logic in the GameState or whatever "knows" about both the player and the level.   In my game, a "Room" is essentially the same as your "LevelSection" idea. When the player collides with a transition region, a change is made to signal that a "transition" is happening, then the game figures a few things out: The direction of the transition (upwards, rightwards, downwards, leftwards) The position of the next room If you know both of these things, then it's pretty easy to decide what to do next. While the "transition is happening now" flag is true you shift the camera a little bit in the direction of the next room. For Mega Man, according to my measurements, the camera moves 4 pixels-per-frame horizontally or 3 pixels-per-frame vertically while transitioning (at 60 frames per second). As you move the camera, you'll eventually move all the way to the next room -- so you basically just keep moving until you've positioned the camera exactly where you want it. Once the camera has moved to the desired location you unset the "transition is happening now" flag and everything goes back to normal. Since you know the position of the room and the position of the camera it is easy to tell when you've hit your goal.   As for moving the player, you do the same thing as with the camera but with a smaller amount of movement. I let my "game state" perform this movement -- my player object doesn't know its being moved because it isn't being updated during transitions.   Obviously, my actual implementation is a bit more complex than what is explained above -- but at the highest level that's what happens.
  2. I'm writing a Mega Man clone right now and have implemented the screen transitions. You can see videos with the transitions here:   The way that I implemented it is to split up the level in to rectangular "rooms". When two rooms connect it gives you an opportunity to perform a transition. Each room has a list of "Transition Regions" which are more-or-less just a rectangle and a transition direction. So if Mega Man is in room #1 then I only check if he's touching transition regions from that room. Once he touches one, a transition is triggered and once it finishes he is now in a different room. Once you're in a different room you only need to check for collisions between transition regions in that room. This allows you to implement both one-way and two-way transitions and prevents you from constantly transitioning back-and-forth in some other cases.   Rather than using magic tiles or "outside of the map" triggers, I would suggest you use a method as I described. It's not a lot of work and it's flexible. I came up with this solution after asking the same question on the Game Development Stack Exchange site:   Essentially the design looks something like this:     As for "where does the code that does the camera movement go", well, that's up to you. I have a class where the "game play" takes place and I handle the screen scrolling there. When you collide with a transition region it sets a flag that says "a transition is happening now". When that flag is true the screen scrolls to the next room. Once you get to the next room it sets the "transition is happening now" flag to false. That way you can "disable" game play while the transition is happening.     That's what I do when my "transition is happening now" flag is true. I don't think it's the Player's responsibility to know about transition movements -- something else should do that.
  3. Hello! Yesterday I completed my first run at implementing an SFML-powered backend for Guichan. Guichan has been a favorite of mine and so far I haven't seen a fully-working SFML backend for it -- so I made one.   You can find it here on GitHub:   Right now it is only the gcn::Graphics portion, I'll be working on getting input implemented in the next few days. I would really appreciate any feedback about this, especially about how it can be improved. I'm hoping that people will find this useful.
  4. [quote name='hdnine' timestamp='1351544638' post='4995166'] At times it lags, jerks and does other wierd stuff with only minimal animations on stage, so it's hard to tell if these are browser issues or if i have some poorly written code. [/quote] How is your rendering loop set up? Are you using setTimeout? setInterval? requestAnimationFrame? It should be possible to draw a reasonable number of things to <canvas> without poor performance.
  5. I recently revised my map rendering code to do some optimization for performance. Before you do something similar, have you tested to see if your current design actually needs performance tweaking? That is, have you taken actual measurements and noticed bottlenecks caused by rendering excessive off-screen tiles? If not, don't worry about it. Focus on other things until it becomes a problem. If you are having an actual problem, one way to solve it is to find only the visible portion of tiles and draw those. This can be done rather easily and cheaply by keeping track of your "starting" X and Y tile positions, and just drawing a "screen width" amount of tiles from your starting point. You simply need to determine the range of tiles to draw based on which ones would appear on screen. Since you screen is 17 tiles wide, your ranges should always be ("starting X" .. "starting X" + 17). The "starting X" can be determined by the position of the view/camera. In my case, it's the left edge of the camera that's used to determine the "starting X". Another approach would be to pre-render your tiles to a larger texture, and then just render the portion that would be visible. If your tiles are not animated this approach will save a lot of extra rendering calls since the tiles are only rendered once.
  6. Mike, I can help you with this but I'm confused as to what you're trying to create, exactly. So far this is what I gather:[list] [*]You want two columns to visually fill the viewport 100% (vertically). [*]You want to stretch a navigation bar across the top of both columns without causing the document height to be greater than 100%. [/list] It possible that you could just create faux-columns using a background image, but the [i]actual[/i] <div> elements won't have 100% height. I would recommend using a technique like this because you'll run into headaches when using height: 100%, especially if you want to introduce margin or padding. If it would be acceptable to use background-image trickery, and just overlay your "real" columns on top, I would go that route.[list] [*]You can read about the faux-columns technique here: [url=""][/url] [*]You can read about an equal-height column technique here: [url=""][/url] [/list] If you need some other kind of solution, we can iterate on your jsFiddle and get things working.
  7. [quote name='thedd' timestamp='1349354921' post='4986744'] I can't find neither sf::Clock.restart() method and sf::Time class [/quote] Were you trying SFML 1.6? I recommend using [url=""]SFML 2[/url] instead. The release candidate is pretty solid; I have been using it with much success. The API has changed a bit between 1.6 and 2, so that could account for missing classes/methods/etc. One piece of advice I would give is that you don't want to over-design your game. If you're coming from the C world, write your first iteration as something close to a procedural program, then iterate on that. It's important to have something working to build on, otherwise you could end up designing forever but never building anything that works.
  8. To address your second issue; that of timing, event loops, Win32 API... I have never written a game without some abstraction over window creation and event management. I've written games with Allegro, SDL, and SFML. Being that Allegro and SDL are C APIs, for writing a game in C++ using C++ concepts and conventions, I would recommend you giving [url=""]SFML[/url] a shot. It's what I am currently using and find the API easy to use and pretty much non-restrictive. You can easily create a window and set up a game loop with something as simple as this: [CODE] #include <SFML/Window.hpp> #include <SFML/Clock.hpp> int main() { sf::Window window(sf::VideoMode(400, 300), "Sweet Ninja Power"); sf::Clock clock; while (window.isOpen()) { sf::Event event; while (window.pollEvent(event)) { if (event.type == sf::Event::Closed) { window.close(); } } sf::Time elapsed = clock.restart(); update(elapsed); render(window); } return 0; } [/CODE] Of course, you can write a more "correct" game loop to take things like lag into consideration, but I hope this gives you the general idea. In my experience it helps to have tools that let you write a solution at a higher level, and when you need to dig deeper you can. I feel like SFML provides several of those high-level tools.
  9. I can address only your first problem with a solution that I am currently using (successfully). Rather than creating two separate classes (PlayerControllableBody and AIControllableBody) you can abstract the "Controller" into another object, and let the ControllableBody use it. [CODE] class ControllableBody { private: Controller * controller; public: ControllableBody(Controller * controller); }; /** Interface for controllers. */ class Controller { public: virtual ~Controller() { } }; /** A controller that uses an AI script. */ class AIController : public Controller { public: virtual ~AIController() { } }; /** A controller that uses joystick input. */ class JoystickController : public Controller { public: virtual ~JoystickController() { } }; /** A controller that recieves instructions over a network. */ class NetworkController : public Controller { public: virtual ~NetworkController() { } }; [/CODE] This allows your different control implementations to vary without affecting the objects you want to control. It also allows you to change how an object is being controlled at runtime, by swapping the pointer to another controller. I am using this pattern, which is essentially a form of the Strategy Pattern, in a platformer/jump and run game right now. Here is one such controller's interface: [CODE] class HeroActionController { public: virtual ~HeroActionController() { } virtual bool shouldMoveUp() const = 0; virtual bool shouldMoveRight() const = 0; virtual bool shouldMoveDown() const = 0; virtual bool shouldMoveLeft() const = 0; virtual bool shouldJump() const = 0; virtual bool shouldShootWeapon() const = 0; virtual bool shouldChargeWeapon() const = 0; virtual bool shouldSlide() const = 0; }; [/CODE] So within your ControllableBody, you can "ask" the controller if something should happen, and then act based off of that input.
  10. My game project is written in C++ but makes use of Lua, which is written in C. My logging functions use std::cout to write messages to a log file, but I'm not able to capture [b]print[/b] messages that take place in Lua scripts in the same log file, since the Lua library uses [b]sprintf [/b]and the like. I am using this code to redirect [b]stdout[/b] but am receiving warnings from MSVC about [b]freopen [/b]being unsafe. [code]freopen( "file.txt", "w", stdout );[/code] The warnings are not uncommon, and having found a [url=""]thread about the exact warnings[/url] I decided to redirect stdout using a "stream redirection guard" as described in the thread. The redirection works for [b]std::cout[/b] but not for [b]stdout[/b]. This makes sense to me but I'm not sure how to achieve what I want. So is it possible to get both pointing to the same stream or file?
  11. I'm looking into the IE7 problem... I need to re-download my IE compatibility image for IE7 first, though. As an aside I can offer some minor criticisms: The background on body is centered 50% horizontally which causes it to be off by one pixel if the browser window size doesn't divide evenly by 2. Try resizing your browser slowly to see what I mean. Very minor, but I've had this problem before and it's irritating. You can fix it lots of ways, easiest would be to put the background on a different element with a fixed width. The header/banner is 5 pixels too short length-wise and doesn't line up with the rest of the 940-pixel elements on the page. An accident? Once I get IE7 up and running I'll be able to help a bit more... Edit: Got IE7 up. I don't think this is an IE7 problem specifically... I believe the problem is the background alignment after all. The browser is trying to position the background at 50% and it's causing it to be misaligned sometimes. The fix is as I stated above: put the background in an element with a fixed width and center the element. Your container_12 element should work fine for this task. [Edited by - Maxamor on June 9, 2010 10:12:50 PM]
  12. Color replacement using GLSL

    Thanks to the both of you :) I was able to get it working using both suggestions (dividing by 255 and using an epsilon). Here the the shader source which allows me to effectively "palette swap" two colors with two other colors: uniform sampler2D texture; uniform vec3 color1; uniform vec3 replace1; uniform vec3 color2; uniform vec3 replace2; void main() { vec4 pixel = texture2D(texture, gl_TexCoord[0].xy); vec3 eps = vec3(0.009, 0.009, 0.009); if( all( greaterThanEqual(pixel, vec4(color1 - eps, 1.0)) ) && all( lessThanEqual(pixel, vec4(color1 + eps, 1.0)) ) ) pixel = vec4(replace1, 1.0); if( all( greaterThanEqual(pixel, vec4(color2 - eps, 1.0)) ) && all( lessThanEqual(pixel, vec4(color2 + eps, 1.0)) ) ) pixel = vec4(replace2, 1.0); gl_FragColor = pixel; } Thanks again to the both of you! Note that I am passing in vec3 values instead of vec4, and that's because I'm using SFML2 and it doesn't have a vec4 built in to the library.
  13. I'm interested in performing per-pixel color replacement on sprite-based graphics using a fragment shader and am running in to some issues. My current shader looks like this: uniform sampler2D texture; uniform vec3 color1; uniform vec3 replace1; void main() { vec4 pixel = texture2D(texture, gl_TexCoord[0].xy); if(pixel == vec4(color1, 1.0)) pixel = vec4(replace1, 1.0); gl_FragColor = pixel; } This seems pretty straight forward: look for a specific color (color1), if you find it replace it with another color (replace1). Now the issue I have is it never seems to be able to find any of the colors I pass in to it. For example, the sprite image I'm testing only has 6 colors total, but the only color I'm able to replace is white because it's value is vec4(1.0, 1.0, 1.0, 1.0). I believe that I am not translating the RGB integer values of my colors correctly and thus the shader is unable to find them. If I wanted to find this color: (0, 112, 236) and replace it with (112, 8, 208) I believe I need to divide each of these integer values by 256 in order to get the proper range between 0 and 1. So I'm passing in values like vec4(0.0f, 0.4375f, 0.921875f, 1.0) and vec4(0.4375f, 0.03125f, 0.8125f, 1.0f) but no replacement is ever made. Is this approach no good? What can I do to make this work for me?
  14. Yes, pretty much. That way the objects don't need to know about the camera, they just draw themselves where they are in the world and that's it. it really simplifies things from a coding perspective if you do it this way.
  15. The way that I have solved this problem in my current project is thusly: my game objects don't know the difference between their "world" and "screen" coordinates. The tiles don't, either. Currently I have a "camera", which is nothing more than a rectangle, that can be moved through the world to see different parts of it. The most important thing I did was to enable my drawing functions to apply an "offset" to drawing coordinates. That way you can draw objects at their "world" coordinates, and if you apply the offset of your camera, then they will appear at their proper places. So, what you end up doing is something like this: * We're going to draw the scene * Apply the offset of the camera to the graphics system * Draw all of your tiles in the visible area at their "world" coordinates * Draw all of your objects in the visible area at their "world" coordinates * Un-apply the offset of the camera to the graphics system * We're done drawing one frame! I simply added two functions to my Graphics object, Vector2D getOffset() and void setOffset(Vector2D) to facilitate this. And then my drawing functions like drawImage(image, x, y) use the offset internally to draw things at the right place. If you implement it this way you only have to keep track of the camera's position and then apply it to the graphics system at the right time to draw everything in place.