next »

[Alessio]

Well, let's cut down about Hex, since they're everywhere anyway, even for forum colors

Why are non-Xinput gamepads so damn hard to implement???   They look even harder than making a decent game mixed with D&D and GML!!!

I think i've found out some methods though. The problem is that... well, they don't disable keyboard controls.
I mean, if i have joypad connected to the PC, the "kLeft" variable will not be equal to a keyboard press function but to the analogic stick ones. because my format is:

Code:

kLeft = joystick_xpos(1) <= -0.25;
kLeft = keyboard_check(vx_left));

If the joystick is found, the first is run, else the second will.

Doesn't seem to work with scripts, though. For the "button press" i've made this script:

Code:

if (joystick_check_button(1,3) and notPressed)
        {
            notPressed = false;                                                                          
            kJumpPress = true; 
        }
        else if (!joystick_check_button(1,3) and !notPressed)
            notPressed = true;

And for the "button release" i've made the reverse:

Code:

 if (!joystick_check_button(joypadNumber,buttonNumber) and !notReleased)
        {
            notReleased = true;                                                                          
            kJumpRelease = true; 
        }
        else if (joystick_check_button(joypadNumber,buttonNumber) and notReleased)
            notReleased = false;

This seems to work, actually but, as i've mentioned before, this isn't going to replace the "kJumpPress" (for example) with another variable but will set only that when "kJumpPress" is true then something will happen. But i'm not assigning "kJumpPress" with anything at all. That's what is just frying my brain for hours! My inputs are stored in scripts.

One is scrInput which stores keyboard and (in future) xInput controls and calls another one that is scrJoystickSupport if xInput gamepad is not found. in the last script i have other two scripts, the ones i've shown above. only "kJump" is assigned to a joystick variable, the "kJumpPress" and the "kJumpRelease" aren't. So while i can't use directional keys in the keyboard i can use "Z" (the key i've used for Jump) and the joystick button "3" altogether. Some games actually permit to use Keyboard and gamepad simultaneously. I believe this is accomplished by switching to "keyboard" mode when a keyboard control is pressed and switches to "gamepad" mode when a gamepad control is pressed. Other games just require to switch keyboard mode and gamepad mode manually into an option menu. My case, though, is a bit unpolished.
Is there a way to assign kJumpPress or kJumpReleased to these two scripts?

I've also a question about the script with the bitwise operators that @Polly posted for me. I've indeed tried to use these and they probably can work with "kJumpPress" and "kJumpRelease" but i may be wrong.

I've found it pretty hard to understand anyway and it doesn't even work properly for me since, everytime i try to run these, it gives me "FATAL ERROR":

############################################################################################
FATAL ERROR in
action number 2
of Create Event
for object oPlayer:

global variable buttons_current(100000, -2147483648) not set before reading it.
 at gml_Script_scrJoyKeyPress (line 3) - return (global.buttons_current & mask) && !(global.buttons_previous & mask);
############################################################################################
--------------------------------------------------------------------------------------------
stack frame is
gml_Script_scrJoyKeyPress (line 3)
called from - gml_Script_scrJoystickSupport (line 22) -     kJumpPress      = scrJoyKeyPress(3)                                    //scrButtonCheckPressed(1, 3);
called from - gml_Script_scrInput (line 45) - scrJoystickSupport()
called from - gml_Object_oPlayer_CreateEvent_2 (line 26) - scrInput()

This happens everytime i try to use global variables. The script is indeed put into my player's Step Event. Really, global variables are pure hell for me!
The code itself seems not very clear to me, since it looks like advanced stuff to me.

[Polly]

You need to assign a value to a ( global ) variable before you can read it. In case of the example i posted simply put "global.buttons_current = 0;" in the create event of the object that's processing the joystick buttons input.

[Alessio]

Well, i simply had to put "global.buttons_current = 0" before "global.buttons_previous" because that's what would cause the "not set before reading it" problem: indeed now i don't have it anymore. Effectively i'm setting a variable that is not set in the first place. I don't know if it was meant to be put first but if i do it gives me error, really.

It also doesn't work very well to me. I may use it incorrectly, though. I just assign my "kJumpPress" to "scrJoyKeyPress(numb)" but i'm not sure if that's correct. I indeed use custom variables like "kJump" to define a control, i don't use the code or script directly.

[JohnsyJohnsy]

a quick question about a 3d layered (think dwarf fortress) map format I am making
applicable to 2d format too actually

say I want to make a human readable map format (ascii) to write a map in,
I want to say which tile will have a floor and which a wall and which a stair and which is open space.
on top (pun) of that there can be furniture and other objects in the world

what are the options I have to describe the kind of floor AND what is on top of it?

it's sort of impossible offcourse, say a wall = #  and a floor = . and a chair = C and open space = ' '
now you dont know if this chair is floating in open space or on a floor here

..........
....C....
..........

what are the options I have ?

[ProgramGamer]

DF makes them blink in order to periodically display everything.

[JohnsyJohnsy]

ah, I dont mean how to display it, in my game it will be visible since its not an ascii game, but how to write the map format itself 

[InfiniteStateMachine]

Does anyone have any resources that go over how get c# to interact with a struct defined in c code?

For instance I have this struct defined in C :

struct ImageData
{
   int width;
   int height;
   unsigned char *data;
};

and I have a couple exported functions that look like this :

LIBRARY_API struct ImageData load_image(const char * const pathIn);

I assume that at a base level I need to re-define the struct in c# and then use some attributes to explain how it should marshal the types but that's kind of where I'm stuck. Here's some of the problems I've found.

1) All the examples use fixed arrays as members of their struct. AKA int[10]. I use an array of bytes (unsigned char) of which the size is not known at compile time.

2) This may or may not be a problem but I don't want .NET to do any memory management. I plan to handle that by exporting this function : LIBRARY_API void destroy_image(struct ImageData image);

Anyways google hasn't been my friend today


EDIT : It seems like I might be expecting too much from PInvoke. Looks like trying to do something like return a struct isn't something PInvoke can really do. I can use a struct as an outparam though. I don't really want to change my function signatures just so I can export to C# so maybe what I'll do is just make a wrapper and use that to export. Then at least my c code is clean of all the export macros etc.

EDIT2: Well I have a solution and it involves re-designing around not returning a struct. So I made a different header/source called exports.h/c which call into my library. I'm actually fairly happy with it because this keeps my c library clean of macro export madness as well as removes the need for the c# user to explicitly release any resources. The only problem is that if I want to access my unsigned char array of pixel data in c# in the future I'll be back at this same problem.

Here's how the signature changed

LIBRARY_API void export_rotate_image_90_cw(const char * source, const char * dest)

which now calls into this function (and saves out the result to a file):

struct ImageData rotate_image_90_cw(struct ImageData imageData);

the wrapper function both allocates and deallocates the memory it uses so there should be no potential for a leak.

[ThemsAllTook]

what are the options I have to describe the kind of floor AND what is on top of it?

Unless your possibility space is small enough that you'd have enough unique ASCII characters to express each combination of floor and furniture, you'll probably need to do something multilayered. Layer 1 would describe the floor, layer 2 would describe the furniture and empty space that's on top of the floor, layer 3 would describe the ceiling, etc. Not the best for human editing, but should be reasonably usable. You could also interleave it (as in, each pair of characters represents the floor and furniture at that position, so your floor map becomes twice as wide in text and every other character is a tile boundary), but I suspect that would be much worse for editing.

Another possibility would be to automatically fill in the floor under furniture with whatever surrounding type is most prominent. If you put a chair in the middle of the room and all 8 tiles around it are floor type 1, it's reasonable to fill in the blank and assume that the chair also has floor type 1 under it. You'd need to write up clear and explicit rules for how floor types are inferred, but it could totally work if you don't need to be able to express something like a chair on top of empty space surrounded by floor.

[JohnsyJohnsy]

You'd need to write up clear and explicit rules for how floor types are inferred, but it could totally work if you don't need to be able to express something like a chair on top of empty space surrounded by floor.

Yes thanks, I think I'll go with this route, ought to be possible and the limitations that it has are workable with for me.
cheers!

[Polly]

Well, i simply had to put "global.buttons_current = 0" before "global.buttons_previous" because that's what would cause the "not set before reading it" problem: indeed now i don't have it anymore.

That fixes the compiler error, but also renders the entire script faulty. The whole point of the "global.buttons_previous = global.buttons_current" line is to cache the state from the last frame .. but when you're setting that variable to "0" each frame, the cached value won't be correct ( obviously ).

[BorisTheBrave]

I don't have all the answers, but in short.
Read the PInvoke docs, should give you a better idea. Structs should work in the obvious way, but you usually need the StructLayout attribute on them to force the .NET runtime to layout the memory the same way C does.

If you have any array of Foo in C, then use "Foo*" in C#, as "Foo[]" is for managed arrays, which are not C arrays. Remember in C, there is basically no difference between Foo* and Foo[] (guys, no need to nerd snipe on this).

It's best to write things in a way that doesn't require memory management if you can, but often it's unavoidable. The C-API typically exposes functions alloc_my_foo and free_my_foo or the like, which you then manually call from C#. There isn't any memory management for memory created in C, only stuff you create in C#. As ensuring the free function gets called can be a huge pain, I strongly recommend anything which is allocated like this is wrapped in an IDisposable C# class with a finalizer that calls free_my_foo. That way, you can use using blocks to manage the memory, and even if you screw up, the GC will sort things out for you.

In fact, except for trivially small APIs, I would recommend wrapping everything behind C# classes.

[InfiniteStateMachine]

I don't have all the answers, but in short.
Read the PInvoke docs, should give you a better idea. Structs should work in the obvious way, but you usually need the StructLayout attribute on them to force the .NET runtime to layout the memory the same way C does.

If you have any array of Foo in C, then use "Foo*" in C#, as "Foo[]" is for managed arrays, which are not C arrays. Remember in C, there is basically no difference between Foo* and Foo[] (guys, no need to nerd snipe on this).

It's best to write things in a way that doesn't require memory management if you can, but often it's unavoidable. The C-API typically exposes functions alloc_my_foo and free_my_foo or the like, which you then manually call from C#. There isn't any memory management for memory created in C, only stuff you create in C#. As ensuring the free function gets called can be a huge pain, I strongly recommend anything which is allocated like this is wrapped in an IDisposable C# class with a finalizer that calls free_my_foo. That way, you can use using blocks to manage the memory, and even if you screw up, the GC will sort things out for you.

In fact, except for trivially small APIs, I would recommend wrapping everything behind C# classes.

Yeah that's the conclusion I came to as well. Right now since I allocate and deallocate everything within a c function call the p/invoke method works but that only goes so far. This is what I did which solves my immediate needs.

https://github.com/AlexMcGilvray/Image-Manipulation-Toolbox/blob/master/ImageManipulationPlayground/exports.h

Now I'm needing more bi-directional communication and the following stackoverflow link seems to be the cleanest.  

http://stackoverflow.com/questions/10223186/c-cli-wrapper-for-native-c-to-use-as-reference-in-c-sharp

I can still have my library with no CLI regions and just make an export layer in c++/CLI so those who want the c# bindings can have them but those who don't won't have a bunch of build/CLI pollution.

In regards to my array problem. I'm assuming to use Foo* I'll have to put that in an unsafe region correct? I didn't see anything about that on the msdn docs I was reading but maybe I was looking at the wrong section.

[Abadox]

I've been working on an html5 game. My engine is currently using a variable time step because at the time I started writing it I was fairly convinced of the reasoning behind this method. However, I'm beginning to think that in a pixel style game this might not be the way to go. I end up having to deal with tunneling, rounding everything to get integer pixel values, and various other issues, and In the end I've had to cap the timestep to 30 fps minimum anyway,and accept slowdown after that. It seems like variable timestep is "the way one does these things", but I wonder if it's just not suitable for low resolution pixel games. Does anyone have feelings about a variable timestep versus fixed? Am I missing something? I'm just looking for the input of people who may have more experience with this than I do before I go in and refactor my code. Thanks.

[voidSkipper]

I've been working on an html5 game. My engine is currently using a variable time step because at the time I started writing it I was fairly convinced of the reasoning behind this method. However, I'm beginning to think that in a pixel style game this might not be the way to go. I end up having to deal with tunneling, rounding everything to get integer pixel values, and various other issues, and In the end I've had to cap the timestep to 30 fps minimum anyway,and accept slowdown after that. It seems like variable timestep is "the way one does these things", but I wonder if it's just not suitable for low resolution pixel games. Does anyone have feelings about a variable timestep versus fixed? Am I missing something? I'm just looking for the input of people who may have more experience with this than I do before I go in and refactor my code. Thanks.

I don't think variable timesteps are the be-all-and-end-all of game programming.

There are a few factors to consider:
-Total overhead of your game - is there really that much risk of dropped or delayed frames on your target systems? If not, why bother with a delta step?
-Competitive fairness - does your game use shared highscores? Would slowdown give players a competitive advantage? If so, you might need delta stepping.
-Are you trying to emulate the behavior or aesthetic of an older system? You've got a pixel game, you want it to play like the Atari or something - does delta stepping sound good for that? Probably not.

If you do go with delta stepping, you have to make sure you actually have everything else in order too. You've complained about tunneling, but if you're using a variable timestep for physics, all of your collisions should be taking the interpolated positions into account anyway. Your render cycle needs to be completely unhitched from your physics, and needs to take into account how far between physics steps it's calculating (ie, interpolated movement). For a pixel game, this might be a lot of math to end up just keeping sprites at the same position because they're sitting on integer values anyway.

It's normal to have a "maximum step" on variable timestep physics, because shit can get weird if you get a badly dropped frame otherwise, but if you're hitting that maximum step a lot, you probably need to look at whether you're a) being very inefficient, b) being overly ambitious with your minimum system requirements target or c) need to look into offering reduced graphics and/or physics options for lower-end systems. If your actual framerate is a long way off your target framerate, the game is going to play badly regardless of the fixed-ness of your timestep.

[Abadox]

voidSkipper, thanks for your input. It may be that I've half assed the physics a bit. The biggest issue seems to be that in firefox the frame rate is really unsteady. In other words, mostly 60 fps, but then drops way down for a few frames occasionally. I'm beginning  to think that the benefits of a variable time step may be inversely proportional to the resolution of the game.

[ThemsAllTook]

I've found that the benefits of a variable timestep are small, and far outweighed by the drawbacks. Fixed timesteps are the way to go in almost all cases, regardless of the resolution of your game.

http://gafferongames.com/game-physics/fix-your-timestep/

[Polly]

Are you trying to emulate the behavior or aesthetic of an older system? You've got a pixel game, you want it to play like the Atari or something - does delta stepping sound good for that? Probably not.

The thing is that those old systems all had a predetermined / controllable refresh rate. The ATARI 2600 always runs at 60 Hertz in NTSC and 50 Hertz in PAL regions. The ATARI Lynx is capable of 50, 60 and 75 Hertz. But when you're developing a HTML5 game you don't know this beforehand, you don't have any control over this ( nor should you want to ) and the common range is far greater than the "usual" 50 / 60 Hertz disparity.

Of course this doesn't have any implications on whether you should use variable timestep or not, but unless your game is relatively slow-paced you probably do want to match up with the refresh rate of the user.

[powly]

Of course this doesn't have any implications on whether you should use variable timestep or not, but unless your game is relatively slow-paced you probably do want to match up with the refresh rate of the user.

Citation needed, I've always been under the impression that in most cases you can get away with a set update frequency of about ~50Hz without affecting the gameplay too much. Not that I have any reference for this other than testing myself where it usually seemed pretty okay. In general, I'd prefer a variable amount of fixed time steps for robustness and ease of implementation. (Unless you have to change the update frequency which requires fine-tuning everything all over again)

[Polly]

Citation needed, I've always been under the impression that in most cases you can get away with a set update frequency of about ~50Hz without affecting the gameplay too much.

Well, if you for instance use a fixed update frequency of 60 Hertz on a 75 Hertz display, you end up with the following situation.



Every 5th frame will be ( perceived as ) a duplicate frame, which results in a noticeable amount of stuttering.

[InfiniteStateMachine]

Can't that be solved by adjusting the positions of objects by the delta of time elapsed when the render function is called?

EX the fixed update will always return the same value for delta time in the update function but the rendering function might not.