Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 14 Dec 2012
Offline Last Active Mar 13 2013 09:32 PM

Posts I've Made

In Topic: PS3 games in C++..

28 February 2013 - 02:34 AM

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. tongue.png 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.

In Topic: Get unique IDs by reading the Instruction Pointer Register

25 February 2013 - 12:34 AM

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

In Topic: What's your preferred way of letting objects affect the game?

24 February 2013 - 11:29 AM

I can see this being a legitimate approach if and only if your game logic is heavily data-driven and validated by external tools prior to loading into the engine.

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... dry.png


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.

In Topic: What's your preferred way of letting objects affect the game?

18 February 2013 - 03:46 PM

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."

In Topic: What's your preferred way of letting objects affect the game?

18 February 2013 - 11:11 AM

typedef unsigned long coord_t;
typedef unsigned char byte_t;
typedef signed short mobjtype_t;
typedef enum {
} 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.