Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

146 Neutral

About xycos

  • Rank
  1. I'm going to have an array of "pixels" containing red, green, and blue values for each pixel as well as information on the pixel's depth, orientation, and material. I know I don't have enough knowlege to do something like this but I'm going to give it a try first, and see where I messed up later. Anyway, since I'm going to have a rectangular array containing hundreds of thousands, if not millions, of these, I thought it might be a good place to optimize from the start). As far as I understand it, while sizeof(int) and some of the others are not standardized, sizeof(char) is REQUIRED to be 1, according to the specification... of course, I guess this wouldn't garuntee much of anything based on how the hardware chooses to implement it.
  2. I'm wondering which of these options would be best memory or whether they would all be the same to contain 8 bytes of data in a single varriable? - A struct with eight unsigned chars (i'm assuming there's quite a bit of overhead with this) - An array of eight unsigned chars - A long long/__int64 - A void* pointer to a memory location, where I use array-style access to access the eight bytes (I really would rather not do this, it sounds like a recipe for errors).
  3. xycos

    Breakout/Pong game prototype

    Wow, that's the first game I ever made. Yours is much, much, much better.
  4. xycos

    How important is "good" design?

    Hmmmmmmm... okay, thanks.
  5. Hmmm... this is more of a general software engineering question... as I embark on my new peoject, I'm finding that the easiest way of doing things is to have them VERY interrelated. While I do have a distinct class for handling graphics, another for game state, another for the controller, etc., etc., they all reference each other and most classes reference things "higher up" in the hierarchy. I've been told that all this is a VERY BAD thing to do, but the reasons usually given are things like readability and ability for others to extend your code. As this is my own project, I don't really plan on having a big team working on it... on the other hand, maybe it's best to learn early? Also, I haven't taken state changes into account from the very beginning... I'm focusing on getting the game part up and running, then working on adding a menu system later. Did I make a BIG mistake? It's early enough in my project I could probably restructure everything (most of the code I've written so far is proof-of-concept things to learn the engine I'm using, etc., so I could start over without too much of a hastle... but that said, I'd rather not). So, any thoughts (i.e. will I regret my choices majorly later). This is the first solo project of this calibur I've worked on, and the others were not games and seemed to have a very logical structure, so it wasn't a big problem). Also, any tips on how to structure it for best practice (it's a turn-based game, so there are some things that need to only be handled every turn or at specific times, while others (like updating sprites), need to be handled throughout the game). Here's the general structure I have so far: ------------------ A GameSystem thread calls functions in the other classes every tick of the clock. An Environment class (and the classes it has access to, such as Map, Unit, Player, etc.) stores game state AND deals with the logic of changing its own state to reflect player actions, etc. References the controllers. The controller classes (one for each player) also reference BACK to the Environment and deal with accepting input and transforming it into a standard format. The different derived classes (i.e. AI, Input, or Network) all send the same types of messages but need to do different things (i.e. the Input class needs to transform a mouse position the player clicks back into a tile, so that's why it needs access to the Environment, etc., etc.) The Data class contains static references to various data loaded from the disc at the beginning of the game, such as sprites, unit starting HP/strength, etc. Referenced by everything else (all public and static). The GraphicsSystem class are passed the Environment and use the data in it (and the Data class) to draw stuff to the screen. This class just draws stuff, deciding WHAT to draw (i.e. which tiles are visible, GUI boxes, etc.) are all handled in the Environment hierarchy. ------------------ I know that this is a BAD way to do it, but I think if I come up with a "better" way (i.e. more layers of abstraction, etc.), there would be exponentially more coding to do. So... yeah, any suggestions? PS, sorry this post is so rambling, wordy, and newbieish...
  6. Being a first-year (well, second-year now I guess) CSE student, I must say I was surprised at the level of competition in my program. I've had extensive programming experience, including two large(ish) projects I worked on with a team and got a 5 on the AP CS AB test. I'd say at least half of my peers have had a lot more experience than I. However, CSE (at least in my program) isn't much programming. It's more computer SCIENCE, i.e. discrete structures, formal models, boolean algebra, etc., etc.
  7. Thank you, all. How difficult is it to combine OpenGL and SDL, and what would I use each one for? For example, would I use SDL to draw the background layer of the map, and OpenGL to draw character sprites on top of that? Would I use OpenGL to make tiles/background? etc. Thank you, Best of wishes, xycos
  8. Okay, first let me say that I'm NOT trying to start a flame war here, as every other topic I've seen on similar issues seems to devolve into. I apologize if this becomes one. I've been looking around at other topics, the internets, etc., and I get the overall impression that (I'm probably pretty worong here), to do fast 2D, and do it well, you need tgo use a 3D rendering engine (which doesn't make too much sense to me since the Super Nintendo was doing fast 2D/tile-based, so why a 2 GhZ computer with a gig of ram can't is beyond me...). But I see topic after topic here compliaing about how SDL is "slow", and the inevitible next response is "Use (OpenGL/DirectX)". I really, really don't want to go the 3D route, I've had enough trouble with those sorts of things already, and I gather to get 2D working well in a 3D engine, you need all sorts of batching and optimization. This would probably be a good learning experience, but for this proect I want to concentrate more on the AI and other things than the graphics. Additionally, if there are any high-level features I need in OpenGL (such as a particle system, etc.), I should be able to access them fine from SDL, right? If I REALLY must do 3D, I will, but I'm hoping I don't have to. So, my big questions are... 1. Is SDL too slow to work with, specifically for a tile-based game? 2. I gather SDL doesn't support rotation. Does this mean that I'll have to have hundreds of different images, one for every sprite in every possible orientation? 3. Are there any other features I need I'll be sacrificing by chosing SDL (for example, I read SDL doesn't support non-alpha blending... I can't see what other forms of blending I'd need, but can an experienced game designer please warn me if there are any)? 4. Are there any other 2D libraries I could look into that might be faster or more fully-featured than SDL? Note that I'm not really looking for a game library (i.e. Allegro) per se, I'd like to have to figure a lot of things out for myself. I wouldn't be against chosing one if that would really help me out, but I don't want to be locked into certain programming paradigms or given hundreds of features I won't use (for example, I don't need any copllision detection in this game; it's a turn-based strategy). 5. Do you have any suggestions of ways to optimize SDL that I should keep in mind from the beginning (i.e. I was thinking I should redraw every frame from scratch, is this a bad idea?). Thanks for reading! Best of wishes, xycos
  9. xycos

    Good rendering engine

    I'm not too knowledgeable about all this, but I'm of the opinion that pretty much any engine will be as good as another, at least for most ameteur projects. It just depends on what you get used to and can work with. I started out using Irllicht, because it's self-contained and VERY easy to get started with and get something on screen (and it's supposedly quite fast, too). I started doing something in OGRE 3D, but decided instead to write my own engine, which, while horrendously time-consuming and difficult, has also been a positive learning experience. I'd say, unless this is a big project or you're planning to have 100,000-poly models or soemthing, just pick one and roll with it.
  10. xycos

    The D language

    I'm a bit of a newbie, especially to game development... I haven't written any engines or things like that... I want to, hopefully, some day. Anyway, I know C++, but is D a good choice or should I wait until there are more libraries for it? Thanks, Best of wishes, xycos
  11. Sorry to ask another language question, because there are way too many here as it is. Anyway, I'm wondering about using D for game programming. I'm thinking about it mainly because, while I know how to explicitly manage memory, I HATE HATE HATE doing it, and D has a garbage collector but also allows expicit memory management. Anyway, what are the major disadvatages of using D over using C++? Are there enough C libraries out there or will I rewriting hundreds of APIs? Also, I heard it's very similar to C++... not that I mind learning a new language (I learned C++ in ~1 week, knowing Java), but is there an extensive learning curve? Thanks, Best of wishes, xycos
  12. xycos

    Starting Development!

    Learning how to program, is a bit like learning anything: a LOT of work. I'd actually suggest starting with BASIC or something like that if you're not sure this is what you want to do, simply because you can get places faster, so you get more reinforcement. After that, if you want to have access to C++ features but not HAVE to use them, I'd suggest looking tnto "D"... it's just as powerful as C++, does slightly better on most stress tests, but has thing slike garbage colleciton, etc. to make your life easier when you don't need to explicitly manage memory, etc.
  13. Hello. Just a quick question. I'm thinking about starting on another (more ambitious) game project, but I was wondering whether it's best to have an artist beforehand. See, I have zero moddelling/texturing talent, so I usually use programmer art. Is it best to have some idea of how I'll get art beforehand, or just start working with programmer art and worry about that later? Thanks, best of wishes, -xy
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net 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!