Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

160 Neutral

About darkhaven3

  • Rank
  1. darkhaven3

    PS3 games in C++..

    Daaark, it might just be me, but I think it's misleading to say "you can't do it without Sony's say so", because that's not strictly true in all cases.  It is entirely possible to write raw C or C++ using PSL1GHT or the leaked v1.92 of the official PS3 SDK and then compile and run programs on the Playstation 3 natively.   I'm a little behind on my PS3 homebrew scene-ology, so I'm not sure if the private key used to sign official software is still a valid means to sign your code to run it on the Cell without modification. IIRC this is a vulnerability that isn't exactly patchable without invalidating all prior officially licensed software on the market in one fell swoop. Maybe this is something the OP can look into.
  2. I still don't understand why you can't just say int id=random()*random()>>random() or something similar if you absolutely must have a totally random and unique ID every time and do checks to make sure you're not getting identical ids every time, and of course you can map the results of your random id assignment to some meaningful array of structs describing the widget or whatever
  3. Really? All I can see is the many hundreds of ways this can crash and burn in a series of amusing ways... more so when you consider the follow up reply about not sanity checking the results...   Sure it can crash and burn if I care to introduce bad definitions in the frametable. Who cares? If the function called by a frame for a particular mobj_t says "You can't move here because I said so", then the mobj_t shouldn't give a damn. All that would happen is the mobj_t would stop moving in that direction, and possibly attempt to move in a different direction arbitrarily. It's not an mobj_t's responsibility to determine where it can move in this specific context; it's handled at a higher level. All an mobj_t is responsible for is itself, or being the target of another mobj_t in special cases (monster infighting, or the player being the target of a monster, mainly). And even in that case, mobj_t's typically don't care if they are targets of one another, and can't directly modify one another's target reference; they will attack one another until it is somehow resolved by other mechanics, typically by means of one mobj_t changing targets to the player or another monster, or entering its death state.   It seems simple and concise enough to be easy to debug and easy to implement, and it seems like it would be quite fast, especially in the context of a 2D sidescroller.
  4. It's heavily implied by the design approach that I'm not going to just allow any frame to start calling functions designed to load a map or initialize SDL or anything, just by convention of how the function-pointer list that the frames reference works. I imagine it will work well enough for the sidescroller I intend to use it with where there's not a whole lot of elegance in object management required. Example being: "Object A tries to move in the direction of object B. Do whatever the function to move this object says to do. I don't care to sanity-check the results; the function will resolve that on its own. The end."
  5. typedef unsigned long coord_t; typedef unsigned char byte_t; typedef signed short mobjtype_t;   typedef enum { MOBJ_CREATE=0, MOBJ_ACTIVE, MOBJ_ATTACK, MOBJ_PAIN, MOBJ_DEATH, maxmobjframes; } mobjstates_e;   typedef struct { mobjtype_t type; frame_t* mobjframes[maxmobjframes]; coord_t mapx,mapy; mobj_t* target; } mobj_t; ? mobj_t represents every possible object in the game world, including the player. mobj_t contains a list of pointers to a master "frame list" that defines things like what graphic should be displayed for this object at this frame, what the next and/or previous frames for the current one are, and a function pointer to describe what needs to be done by this object this frame. mobj_t frames only have access to certain functions in a master list which should, by convention, only interact with other mobj_t types, and what object that ends up being is dependent on mobj_t.target. Objects can do whatever the hell they want to each other after this point.
  6. HTML5 and JavaScript (?) are the target languages here, it appears. For such an application, HTML5 and JS should be more than enough.
  7. darkhaven3

    PC vs Console

    I vastly prefer PC to play videogames in nearly all cases, although I do have soft spots for games like the Xbox port of Minecraft so I can play with a friend of mine who doesn't have a working PC at the moment. That being said, I have consistently witnessed ignorant (not an insult) individuals on Nintendo Network, Xbox Live, and Playstation Network who think "PC games are full of hackers" and "X is the most powerful gaming machine out right now". The insufferable arrogance of 12-year-olds screaming racial expletives over the internet at me because I killed them on Call of Duty is also not worth the trouble on Xbox or Playstation... Not to say that's everyone, but I've frankly had enough of it.   That  being said, I am not adverse to programming for the Xbox 360 nor the Wii. I actually had quite a lot of fun at the time getting a simple JPEG decompressor routine to get up and running on the Wii back when I was new to it! And there's just something really nifty about spending a late night finishing up X or Y tweak on a raycaster engine you've been working on for Gameboy Advance, and being able to take it with you and show people in the palm of your hand, on the original hardware.   So in short, I think console gaming is more or less intolerable in most cases and I absolutely prefer playing on PC. However, as far as programming goes, I have a fondness for the Gameboy Advance, the Wii, and several other "vintage" consoles.
  8. You're basically going to make an engine if you're not going to use a pre-built one, regardless of simplicity. Using a pre-built one might save you some time, but that time is taken back by figuring out how the engine works and how you can apply it to your game concept.   For something so simple, though, you might just be better off writing your own code from scratch, IMO. It shouldn't be exceedingly difficult.
  9. darkhaven3

    What is OpenGl ? Should i start with it ?

    id Tech 4 and Unity 3D are rather different technologies from UE2.5-3. Comparing between these three engines running identical hardware, Unreal Engine 3 is going to invariably be slower than id Tech 4... Not necessarily "worse".   Don't get me wrong, I personally hate the Unreal Engine and have hated it since 1997, but what I was really trying to say was "a game engine written X years ago is going to run faster than game engine Y written yesterday." Get what I mean?
  10. darkhaven3

    What is OpenGl ? Should i start with it ?

      Hardly true at all. If Doom, the Quakes, and then Rage have proved anything, it is that there is still a lot left to be done on even current-gen hardware. Rage running at 60FPS on the equivalent of a Radeon X1800 is nothing to laugh at, and neither is the notion of writing one's own graphics engine. As far as having "nothing left to invent", again, not true at all. A game made with Unreal Engine 3 will look different and run much slower (invariably) than a game made using, say, id Tech 4 or Unity.
  11. darkhaven3

    What language should I write my indie game in?

    If you know Java, stick with that! If you're SPECIFICALLY trying to learn a new language, try out C or C++.
  12. ... And thus, a misconception I've had for years about what rand() is doing was today blasted out of my mind. Wow.
  13. darkhaven3

    engine design

    Then maybe that individual shouldn't be writing their own game engine just yet. It is common knowledge that a good game in this modern era generally requires that there be a standard format or formats for images in place that you will read from the disk, audio of some form, and some kind of user interface. I believe all of these can be cleanly separated into core components of a game engine, and you don't have to be the most intelligent person in the world or even a programmer at all to understand these requirements. How does one even implement 'camera panning' without some concrete requirement of how it's going to be used? I'll usually fall into the "what if the end-user wants to do this or that" trap... and will ultimately end up writing a bunch of code that never gets used. Personally, I'd rather write a feature for a requirement of the game, instead of some generic feature. And then, if I notice this may be a nice chunk of code to use again, factor it out.[/quote] This implies that the programmer has no idea what kind of game he will be programming, or will be somehow working on-the-fly without some kind of design document about how the game should be implemented written down first. If you are writing a text adventure, you know you will not need camera control of any kind. If you are writing some kind of 2D or 3D game, you will certainly need some kind of "camera" in as abstract of a sense as I can put it. Don't need a particular camera feature for your game? #ifdef it out in your game header files or something. Writing software without concrete requirements can be very difficult, which is why I believe writing engines can be so difficult. Writing a game/demo/unit test is so much easier because those applications inherently come with a set of requirements which have purpose, and can help keep a programmer focused.[/quote] If you don't have a game design document that clearly outlines the scope and format of the game before you start writing code, I believe you have more serious issues to attend to than deciding how to write your engine. These are all issues that seem easily resolved at the planning stage; if I'm writing a game for Gameboy Advance, I can have it on good faith I'm not going to be needing things like vertex coloring and DX11 tesselation. Likewise, if I'm writing a game on PC and I want it to look fancy, I can implement these features and I will know that I will need to have this information stored in some kind of consistent format. In short, while I respect that you might find it difficult to write a game engine, it feels like you are assuming that everyone just writes game engines without some kind of idea as to what kind of game the engine will be used for.
  14. darkhaven3

    Once you go OO, you never go back?

    I think I can safely say that the above is pretty much a nonexistent issue. In C, you cannot "access every function and every variable"; a static int declared within a function remains within the scope of that function, and cannot be overwritten directly. Of course, it's quite possible to do so intentionally, in the same way that it is with any OOP language that doesn't do bounds checking on arrays, if you get where I'm going with that. If I don't want a function to modify something, I'll pass it a pointer-to-const (i.e. const int* var; ). If I want a variable to be available locally to a function, I will initialize that variable within the function that requires it. Not much more to it than that, honestly. If it comes to a point where data is being modified that I didn't intend to be modified, I can always have a look at that nifty map file the linker generates, which is available to both C and C++ programs.
  15. darkhaven3

    Once you go OO, you never go back?

    After being a C++ programmer for a little while and dabbling with Java, I have to say that in my opinion object-oriented programming is relatively worthless to me. I honestly don't see why I should ever bother worrying about whether or not a particular set of functions can "see" each other, or whether or not I can make two functions with the same name. Why would I ever want more code obfuscation like that -- two functions with identical names that can do two completely different operations? Why on earth would I ever want such a thing? But this is of course only my opinion. I'm not unique in the way I think, surely, but I'm also probably not at all a rare, dying species of programmer. A recent example that I can think of is the IW engine (used in every single major Call of Duty title). It's based directly on the Quake 3 source, so I can imagine it's probably in C still.
  • 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!