Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

154 Neutral

About ishpeck

  • Rank
  2. @zerotri: I'm running Ubuntu so Windows/Mac tools won't help much. I'd been bit-picking the crap out of the code thinking that I was leaking memory somewhere. I went so far as to get rid of all memory allocations that weren't necessary to load the textures into memory. It still happened. @Ohforf sake: I think you're right. I think I was just cooking my GPU alive under the insane pacing I kept it at. I went in added some pacing/control to the code and it hasn't slowed down like that again. Thanks, guys, for your ideas. [Edited by - ishpeck on March 27, 2010 8:41:16 AM]
  3. Quote:Original post by jyk Are you sure you're managing your resources correctly? Are you doing anything odd like creating new SDL surfaces or OpenGL textures each frame (which would be bad) and never freeing them (which would be worse)? As I said before, I'm not fiddling with memory at all by the time this starts up. All the surface creation takes place before I even see the first frame rendered. I would imagine if I was making a zillion surfaces that it'd be apparent long before I'm seeing these slow-downs.
  4. I'm using SDL and OpenGL for my 2D sprites because I want to be able to rapidly scale and twist them on the screen and SDL's software rendering runs like molasses on a cold day. I built a little app that loads a bunch of .PNG files into texture memory and spins them in-place on the screen. Some framerate data is collected and I'm using glOrtho to make it so the mouse scroll wheel will "zoom in/out." This is all my app does. Everything appears to work great for about twenty minutes. My sprites are displayed correctly on the screen and things are hunky dory for about that long. After that time has elapsed, the framerate drops from about 1,200 FPS to about 100 FPS. I surrounded each major chunk of my main loop in SDL_GetTicks() calls to determine which area was taking the longest and which area's execution time changed. I've narrowed it down to a single line: SDL_GL_SwapBuffers() seems to run dandy for about twenty minutes before it suddenly takes as long as 6 miliseconds to even swap my frame buffers. I'm on the OpenGLtarded side of things so I'm not sure what, exactly, would cause swapping my frame buffers to run great for the first twenty minutes of the program's life and suddenly stop. I don't do any new memory tricks or any data loading whatsoever in that time. My usual places for digging up documentation aren't helping me much. I obviously don't know enough to use the right search terms or whatever. My Google-fu is weak. :(
  5. ishpeck

    SDL. would YOU recommend it ?

    Quote:Original post by FlyingSolo I'd be far happier going on the recommendation of people far more knowledgeable and experienced than me since I'm pretty new to opengl. I've used SDL for a long time now and have recently started folding OpenGL into my SDL programming experience. I've used Allegro (back in the day), SFML, and tinkered around with DirectX. SDL is the most intuitive and best documented of all the libraries I've used. Combined with OpenGL, you can get some pretty fast graphics in place with lucid audio and user input handling. SDL has several child projects that help round it off more thoroughly. SDL_image is pretty much necessary for me because I tend to store my sprites in a format other than .BMP. SDL_ttf is a bit obnoxious and I just defer to OpenGL for showing text. SDL_mixer is rather necessary and not very hard to learn. I've never bothered with socket programming so I can't comment on SDL_net. In short, I'd recommend SDL. It's portable and it just plain works. Maybe I'm just too dumb but I never could get SDLdotNET (the C# wrapper for SDL) or SFML to really work for me and DirectX gives me ulcers. I've gotten the best results in the least amount of time with good, old-fashioned SDL projects.
  6. ishpeck

    Sprites vs. Memory Limits

    Quote:Original post by Captain P That's not really where you're going to save a lot of memory, so why bother capping that at the engine-level? It's an arbitrary limit that doesn't help much. Right now, sprites are consuming the absolute most memory. This project is trying on many levels to enforce a spartan design philosophy. Quote:Original post by Captain P Enforce it in your levels, not in your engine. There really aren't "levels" per se. The Sprite Indexer loads all the sprites for the "level" anyway so enforcing it in the indexer is enforcing it for the "level." Quote:Original post by Captain P If you then decide to build a game that targets higher-end hardware, you don't have to remove or up the cap, I'm already targeting hardware that significantly out-classes my design. My limit will be way below the hardware's abilities. Quote:Original post by Captain P And if you absolutely must hard-code such a limit, at least make it externally configurable. Probably will be. Still needs a default value. And I still need to know generally where most games are likely to need it to be.
  7. ishpeck

    Sprites vs. Memory Limits

    Yeah, I'm not sure why an arbitrary upper limit set by me is any different than a memory limit. In the end, you've got to build your game in a way that will be able to work with either boundary. In my current project, I can say with great confidence that I won't come anywhere near a hard limit of, say, 100 sprites so I'm not the least bit worried about bumping that limit. I'm still curious how many images were used in other games. I figure if I take the number of sprites that were used in a heavily-animated game like one of the newer Castlevanias, I'll have more than enough room to operate in for my minimalist designs.
  8. ishpeck

    Sprites vs. Memory Limits

    Quote:Original post by Captain P Setting a maximum number of sprites is likely not a smart thing to do ... Why not?
  9. I'm building a sprite indexer to handle all the visual assets in my games. I'm pretty sure I won't come anywhere near the memory limits of the hardware I'm likely to run on but I still want to set a hard maximum of the total number of sprites my engine will load. How many sprites do you suppose a game like, say, Castlevania had in it? That ought to give me a good ballpark figure for workable memory limits.
  10. One of the most important things to remember with MMO economies is that you need to have replenishing resources so that more players can enjoy the game. But you also need a way to constantly bleed those resources back out of the game or you'll deal with hyperinflation. This is true for all arbitrary economic environments. In the United States, money is dictated arbitrarily by a central bank setting key interest rates. Money enters the economy by lowering interest rates and is bled out by raising them. In this manner, one may theoretically keep the balance of value behind dollars in the world. (I don't believe it works but that's another topic entirely) As a game designer, you have a job very much like a central banker: You are trying to find the proper method of trickling resources into a world and then out in a manner that will maintain playability. My solutions (like my economic theories) are always more radical than most. One of my least radical solutions is to ensure the only way you can restore HP is by paying for the service from some healer/wizard/doctor type NPC. So doing would guarantee that money leave the world at a rate commensurate to its introduction. But when I suggest these sorts of solutions, I'm laughed at as the Hayekian loon that I am.
  11. ishpeck

    benefits of c#?

    C# is really good. You can't go wrong with it. You can gain a lot of portability by using C# and It won't work on all the consoles but it'll work on many platforms.
  12. Whenever I build a prototype, if the core gameplay isn't fun, I don't bother working on it anymore. But that's just me.
  13. ishpeck

    Very Complex Combat

    Quote:Original post by Kylotan "It is actually impossible to compute an optimal strategy because it is self referential." - this isn't true; mathematically you can still work it out. Moreover, it'd be gratuitously lame if it were true. As you explain, part of the point in varying the combat choices in this system would be for there to be a mathematically superior decision. The variety of choices must, therefore, yield circumstantially superior results -- otherwise, there would be a jillion options that all have the same result that would totally kill the entire sense of "choice" in the whole system. Like the line from the incredibles: "Everyone is special, Dash." "Which is another way of saying nobody is." One of the greatest dangers we all fall into is assuming that Paper, Scissor, Rock is implicitly superior than something else. Now, the balancing attributes of cost vs. reward analysis should indeed be there -- but they implicitly demand that some choices be obviously better than others in varied circumstances.
  14. ishpeck

    Story Vs Gameplay in RPG

    "Story" is usually used as an excuse for bad gameplay. Good gameplay, however, has never been used as an excuse for a bad story.
  15. I think any game that goes from design to playable has some love in it. Some developers are just better lovers than others.
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!