Topic: if self.isCoder(): post() #Programming Thread (Read 908360 times)

Arx · « **Reply #6315 on:** September 15, 2014, 02:20:56 pm »

I'm pretty sure Kerbal Space Program is Unity as well, and Just Cause 2, whatever that is (I think it's well known).

Putnam · « **Reply #6316 on:** September 15, 2014, 04:08:13 pm »

Just Cause 2 is not unity.

EnigmaticHat · « **Reply #6317 on:** September 15, 2014, 05:25:54 pm »

Unity as I understand it is summarized perfectly by the name. It combines several things into a convenient package so that making a game is quicker and easier.

Sergius · « **Reply #6318 on:** September 15, 2014, 05:32:07 pm »

Quote from: Putnam on September 15, 2014, 04:08:13 pm

Just Cause 2 is not unity.

It's probably one of the Unreal engines.

Skyrunner · « **Reply #6319 on:** September 15, 2014, 07:56:34 pm »

I would like to make a ray tracer, but it seems so hard...

alexandertnt · « **Reply #6320 on:** September 16, 2014, 06:09:07 am »

I have been using Unity for a while and I quite enjoy it, but not having render textures in free is real annoying. I have to resort to set/getPixels() and texture.Apply() which is ridiculously slow.

Speaking of Unity, is there some concept of joint stiffness? Sometimes when I use ragdolls (which are a skeleton of configurable joints and rigidbodies), they land in such a way that causes them to keep wobbling along lengths of bones that aren't contacting the ground (eg the spine). Rotational dampening isn't what I want (that causes all bones and the entire ragdoll to stop any rotational movement entirely when in the air).

Squeegy · « **Reply #6321 on:** September 16, 2014, 07:35:54 am »

I normally don't like XKCD, but today's strip is fucking spot on:

McDonald · « **Reply #6322 on:** September 18, 2014, 04:18:59 pm »

I made an AutoHotkey script which makes your keyboard lights create a little show.
(Giant wall o' text)

Spoiler (click to show/hide)

Bauglir · « **Reply #6323 on:** September 20, 2014, 10:59:52 pm »

Okay, so I'm trying to do something that's probably pretty stupid. I'm writing a bit of code in C. I have an array of chars (1 byte). I need to work with 8 bytes at a time, so I've set a long long* pointer and dereference it every time I need to get data. I then need to move that pointer 4 bytes further into the array once I'm done with each iteration of a loop, so that the lower 4 bytes of the last iteration become the upper 4 bytes of the next.

I'm having trouble with that last step. Every time it's supposed to shift, I instead find that it's pointing to something else entirely. The upper 4 bytes are always the same, and the lower 4 bytes are always empty. Notably, the upper 4 bytes after a loop iteration should always be empty; it seems like I've offset my address by 4 bytes in the wrong direction. The entire loop smears those 4 bytes across the entire array, so I'm not just straight-up moving backwards, either.

Here's one form of the clearly incorrect syntax I'm using:

Code: [Select]

selection = (long long*)&shiftChecked[index];
where selection is a long long* pointer that points to the data I'm operating on, shiftChecked is an array of longs whose starting address is the same as the array of chars that I'm working on, and index is which of those I'm working on right now.

That fustercluck of spaghetti code was the result of trying to take the actual pointer arithmetic out of my hands entirely, but it seems to have exactly the same results as the earlier

Code: [Select]

selection = (long*) selection + 1;
How the devil does one even do this?

EDIT: Notably, switching to selection - 1 in the latter block causes the algorithm to work "correctly", but with quotes because it works on the data preceding the array in memory, and also in the reverse of what would be the correct order. If it comes to it, I can exploit this by reversing the binary string that makes up the array, starting at the end, and then unreversing it when I'm done. This is stupid though so if anybody has better ideas I still want to hear them, and even if I do this I'll probably still fuck it up somehow.

Skyrunner · « **Reply #6324 on:** September 21, 2014, 05:23:29 am »

Spoiler (click to show/hide)

512x512 image took around 25 seconds to generate. The second one was created at 1024x1024 then downsampled to 512x512 and took almost exactly four times more to generate. Antialiased version does look better though.

The checkerboard artifacts are because I used a very very naive algorithm to generate the pattern

I'll be fixing that next time.

Orange Wizard · « **Reply #6325 on:** September 21, 2014, 05:31:09 am »

Quote from: Bauglir on September 20, 2014, 10:59:52 pm

nonsense

You broke it. I don't know what "it" is, exactly, but you've broken it.

Spoiler (click to show/hide)

Quote from: Skyrunner on September 21, 2014, 05:23:29 am

Spoiler (click to show/hide)
512x512 image took around 25 seconds to generate. The second one was created at 1024x1024 then downsampled to 512x512 and took almost exactly four times more to generate. Antialiased version does look better though.

The checkerboard artifacts are because I used a very very naive algorithm to generate the pattern I'll be fixing that next time.

That's pretty cool, actually. I wish I knew how to do proper graphics.

Telgin · « **Reply #6326 on:** September 21, 2014, 08:17:47 am »

Without seeing the entire code I'm not entirely sure what the problem is, but depending on what exactly you're doing, I might instead try casting the byte array as a struct and do the pointer advancement manually. I suspect the problems you're seeing with the bytes being in the wrong order might also have something to do with endianness, and casting them to a struct might help since that doesn't do any integer reinterpretation.

So, example (forgive the syntax, I'm used to C++'s struct definitions and I can't remember how you do typedef structs in C off the top of my head):

Code: [Select]

struct something {
    char part0;
    char part1;
    char part2;
    char part3;
    char part4;
    char part5;
    char part6;
    char part7;
};

// This is your original array of chars
char whatever[256];

// Example loop doing something
int i;
for (i = 0; i < 256; i += sizeof(something / 2)) {
    something foo = ((something*)(whatever + i))*;
    foo.part0 = 0;
}

That probably doesn't compile. I don't have any way to test it in a compiler right now. But anyway, here's the idea of how it works: it iterates over the char array, adding half the size of the struct to the i variable each iteration. Inside the loop, it adds that raw offset to the char array and reinterprets whatever is at that memory address as a pointer to the struct, then takes the value of that pointer. I think that makes sense and does what you want. You could probably hard code the sizeof(something / 2) thing to 4 if you know you'll always be moving ahead by 4 bytes at a time.

There is probably a much cleaner way of doing this that doesn't involve raw pointer arithmetic, but off the top of my head I can't think of it.

Did you want to actually use the data as integers? If so then the above approach probably isn't going to work so well. You can probably do something similar with raw pointer arithmetic though, which would help avoid any unintended endianness screwing stuff up in unexpected ways.

Bauglir · « **Reply #6327 on:** September 21, 2014, 09:47:18 am »

I actually don't need to use them as integers, and I like this idea. I am going to try that struct idea.

Incidentally, II, C isn't normally this bad. If you're trying to do something sane, you'll likely be fine. This is just what happens when you need to do bit-level operations on a piece of data too big to fit into a single variable, because you're implementing hardware-level shit in software to prove you know how it works (or, I suppose, if you need to simulate the hardware to test some other thing without potentially wrecking expensive equipment).

EDIT: So I did that, and the problem with using structs is that I can't do the bitwise operations on it I need to - unless I forcibly use shenanigans to cast it to a long long, and that causes endianness problems with the actual operation (which I now realize were there the way I was originally doing it, anyway). I'm going to go with the "stupid" option from above. I don't think there's any way you could've known exactly what I was trying to do though, since I didn't specify, and I still appreciate the help since your strategy does actually do what I asked for.

hops · « **Reply #6328 on:** September 22, 2014, 04:34:46 am »

Do variables in Python have dynamic type?

Putnam · « **Reply #6329 on:** September 22, 2014, 04:36:54 am »

What exactly do you mean?

EDIT: I mean, if we were talking C I'd probably just say "no" right off the bat, so I guess yes?

Bay 12 Games Forum

News:

Author Topic: if self.isCoder(): post() #Programming Thread (Read 908360 times)

Arx

Re: if self.isCoder(): post() #Programming Thread

Putnam

Re: if self.isCoder(): post() #Programming Thread

EnigmaticHat

Re: if self.isCoder(): post() #Programming Thread

Sergius

Re: if self.isCoder(): post() #Programming Thread

Skyrunner

Re: if self.isCoder(): post() #Programming Thread

alexandertnt

Re: if self.isCoder(): post() #Programming Thread

Squeegy

Re: if self.isCoder(): post() #Programming Thread

McDonald

Re: if self.isCoder(): post() #Programming Thread

Bauglir

Re: if self.isCoder(): post() #Programming Thread

Skyrunner

Re: if self.isCoder(): post() #Programming Thread

Orange Wizard

Re: if self.isCoder(): post() #Programming Thread

Telgin

Re: if self.isCoder(): post() #Programming Thread

Bauglir

Re: if self.isCoder(): post() #Programming Thread

hops

Re: if self.isCoder(): post() #Programming Thread

Putnam

Re: if self.isCoder(): post() #Programming Thread