Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Poll

What programming topic would you want the next challenge to be about?  (It might be a good opportunity to focus on a subject you're not familiar with or to reinforce knowledge on one that you already know)

Control Flow
- 2 (2.2%)
Arrays, Strings, Pointers, and References
- 8 (9%)
Functions
- 4 (4.5%)
Basic object-oriented programming
- 30 (33.7%)
A bit more advanced OOP (Composition, Operator overloading, Inheritance, Virtual Functions)
- 18 (20.2%)
Templates
- 8 (9%)
Other (Explain)
- 4 (4.5%)
Working with files?  (Streams)
- 15 (16.9%)

Total Members Voted: 89


Pages: 1 ... 13 14 [15] 16 17 ... 78

Author Topic: Programming Challenges & Resources (#bay12prog) Initiative  (Read 95801 times)

Normandy

  • Bay Watcher
    • View Profile
Re: Programming Challenges & Resources (#bay12prog) Initiative
« Reply #210 on: July 08, 2010, 02:06:56 pm »

Haha, I just spent all morning doing calculus instead of programming a physics engine. Nothing optimizes quite like removing iterations. By having more accurate equations, I can increase the size of the timestep, without losing accuracy. When considering drag, which comes in the form of F=bv2, a naive programmer may simply implement a physics loop as v'=v-(bv2/m)*dt and call it that. However, a little bit of first-year calculus shows that a much better equation is v'=m/(m/v+b*dt). This second equation deviates about 11 orders of magnitude less than the first equation with equal timesteps. Instead of needing to iterate, say, 1000 times per second to get an accurate simulation of drag, I can reduce this down to 25 times per second or even less. Case in point: optimization is in the hands of the programmer, not in the hands of the program.

By the way Blacken, how's Sharplike coming along? I haven't seen any recent activity on it in the past week or so. It's a very complex library and I don't have the expertise to fully utilize it yet, so I'm biding my time and programming other stuff.
« Last Edit: July 08, 2010, 02:08:45 pm by Normandy »
Logged

ILikePie

  • Bay Watcher
  • Call me Ron
    • View Profile
Re: Programming Challenges & Resources (#bay12prog) Initiative
« Reply #211 on: July 08, 2010, 02:54:01 pm »

Looking for a way to make a pointer to an array. Currently I can do this:
Code: [Select]

   rgb foo[8][8];   //rgb is a typedef-ed struct
   rgb *bar;
   
   bar = &foo[0][0];
What I'm trying to get is something like so:
Code: [Select]

   rgb foo[8][8];   //rgb is a typedef-ed struct
   rgb *bar[8][8];
   
   bar = &foo;
so a '*bar[1][1] == foo[1][1]' statement would return true, I could do this with a for loop, but I was hoping there was a faster/cleaner looking way to do so. The language is C if it isn't obvious.
« Last Edit: July 08, 2010, 02:57:33 pm by ILikePie »
Logged

Blacken

  • Bay Watcher
  • Orange Polar Bear
    • View Profile
Re: Programming Challenges & Resources (#bay12prog) Initiative
« Reply #212 on: July 08, 2010, 03:05:26 pm »

A pointer to an array would just be of type Type**. A pointer to a pointer - or, given the way C works, a pointer to an array.

That said, there is almost certainly a better way of doing what you are trying to do.
Logged
"There's vermin fish, which fisherdwarves catch, and animal fish, which catch fisherdwarves." - Flame11235

Normandy

  • Bay Watcher
    • View Profile
Re: Programming Challenges & Resources (#bay12prog) Initiative
« Reply #213 on: July 08, 2010, 03:09:15 pm »

rgb *bar is actually wrong. What you want is rgb ***bar = &foo. Then, (*bar)[j][k] == foo[j][k].
Logged

Blacken

  • Bay Watcher
  • Orange Polar Bear
    • View Profile
Re: Programming Challenges & Resources (#bay12prog) Initiative
« Reply #214 on: July 08, 2010, 03:26:54 pm »

rgb *bar is actually wrong. What you want is rgb ***bar = &foo. Then, (*bar)[j][k] == foo[j][k].
Are you sure? I thought that the C syntax for arrays was simply additive.
Logged
"There's vermin fish, which fisherdwarves catch, and animal fish, which catch fisherdwarves." - Flame11235

Normandy

  • Bay Watcher
    • View Profile
Re: Programming Challenges & Resources (#bay12prog) Initiative
« Reply #215 on: July 08, 2010, 04:57:54 pm »

Not when you have multi-dimensional arrays. Multi-dimensional arrays are pointers to pointers, so that you get an array of pointers, each of which points to an array.
Logged

ILikePie

  • Bay Watcher
  • Call me Ron
    • View Profile
Re: Programming Challenges & Resources (#bay12prog) Initiative
« Reply #216 on: July 08, 2010, 05:18:30 pm »

Code: [Select]
rgb foo[8][8];
rgb ***bar[8][8];

bar = &foo;
still gives me 'incompatible types in assignment'.
Logged

eerr

  • Bay Watcher
    • View Profile
Re: Programming Challenges & Resources (#bay12prog) Initiative
« Reply #217 on: July 08, 2010, 06:20:29 pm »

oh well, at least I learned something.
« Last Edit: July 09, 2010, 10:19:53 am by eerr »
Logged

Blacken

  • Bay Watcher
  • Orange Polar Bear
    • View Profile
Re: Programming Challenges & Resources (#bay12prog) Initiative
« Reply #218 on: July 08, 2010, 07:24:05 pm »

Not when you have multi-dimensional arrays. Multi-dimensional arrays are pointers to pointers, so that you get an array of pointers, each of which points to an array.
Are you sure? I was under the impression that C arrays are memory blocks, and that you could not have ragged arrays in C.
Logged
"There's vermin fish, which fisherdwarves catch, and animal fish, which catch fisherdwarves." - Flame11235

Normandy

  • Bay Watcher
    • View Profile
Re: Programming Challenges & Resources (#bay12prog) Initiative
« Reply #219 on: July 08, 2010, 08:11:24 pm »

eerr, that code is wrong too.

ILikePie, rgb ***bar[8][8]; is not the same thing as rgb ***bar;. Use:
Code: [Select]
rgb ***bar;exactly like I typed.

@Blacken:
Absolutely sure. An array in C is a pointer, and an array of arrays (i.e. a multidimensional array) is an array of pointers - each one of those pointers is independent of the other ones. (probably the source of confusion here - a lot of code, esp. graphics code, uses 1-dimensional arrays to represent 2-dimensional arrays so that they are contiguous in memory, even though these are not 'true' 2-dimensional arrays).

If you try int arr[5][5]; *(arr+5*2+3); this will fail. It needs to be *(*(arr+2)+3); which is a distinct operation.
Logged

DrPizza

  • Bay Watcher
    • View Profile
    • Ars Technica
Re: Programming Challenges & Resources (#bay12prog) Initiative
« Reply #220 on: July 08, 2010, 11:26:58 pm »

Quote
@Blacken:
Absolutely sure
You shouldn't be.

Code: [Select]
drpizza@lunix:~/tmp$ cat dim.c
#include <stdio.h>

int main()
{
        int multi_dimensional[4][4] = { { 0, 1, 2, 3 }, { 4, 5, 6, 7 }, { 8, 9, 10, 11 }, { 12, 13, 14, 15 } };
        printf("%zd\n", sizeof(multi_dimensional));
        printf("%p\n", multi_dimensional);
        for(int i = 0; i < sizeof(multi_dimensional) / sizeof(*multi_dimensional); ++i)
        {
                printf("\t%p\n", multi_dimensional[i]);
                for(int j = 0; j < sizeof(*multi_dimensional) / sizeof(**multi_dimensional); ++j)
                {
                        printf("\t\t%p\n", &multi_dimensional[i][j]);
                }
        }
}
drpizza@lunix:~/tmp$ gcc -std=c99 dim.c
drpizza@lunix:~/tmp$ ./a.out
64
0x7fff6fd8a5a0
        0x7fff6fd8a5a0
                0x7fff6fd8a5a0
                0x7fff6fd8a5a4
                0x7fff6fd8a5a8
                0x7fff6fd8a5ac
        0x7fff6fd8a5b0
                0x7fff6fd8a5b0
                0x7fff6fd8a5b4
                0x7fff6fd8a5b8
                0x7fff6fd8a5bc
        0x7fff6fd8a5c0
                0x7fff6fd8a5c0
                0x7fff6fd8a5c4
                0x7fff6fd8a5c8
                0x7fff6fd8a5cc
        0x7fff6fd8a5d0
                0x7fff6fd8a5d0
                0x7fff6fd8a5d4
                0x7fff6fd8a5d8
                0x7fff6fd8a5dc
That's no array of pointers. It is a single contiguous block of memory.
« Last Edit: July 08, 2010, 11:45:29 pm by DrPizza »
Logged

DrPizza

  • Bay Watcher
    • View Profile
    • Ars Technica
Re: Programming Challenges & Resources (#bay12prog) Initiative
« Reply #221 on: July 08, 2010, 11:45:02 pm »

Looking for a way to make a pointer to an array. Currently I can do this:
Code: [Select]

   rgb foo[8][8];   //rgb is a typedef-ed struct
   rgb *bar;
   
   bar = &foo[0][0];
What I'm trying to get is something like so:
Code: [Select]

   rgb foo[8][8];   //rgb is a typedef-ed struct
   rgb *bar[8][8];
   
   bar = &foo;
so a '*bar[1][1] == foo[1][1]' statement would return true, I could do this with a for loop, but I was hoping there was a faster/cleaner looking way to do so. The language is C if it isn't obvious.
Code: [Select]
rgb foo[8][8];

rgb (*ptr)[8][8] = &foo;

assert((*ptr)[1][1] == foo[1][1]);
protip:
Code: [Select]
drpizza@lunix:~/tmp$ cdecl
Type `help' or `?' for help
cdecl> declare p as pointer to array 8 of array 8 of struct rgb
struct rgb (*p)[8][8]
« Last Edit: July 08, 2010, 11:46:48 pm by DrPizza »
Logged

Outcast Orange

  • Bay Watcher
  • [SOMETIMES_SQUID]
    • View Profile
    • The Outcast Orange
Re: Programming Challenges & Resources (#bay12prog) Initiative
« Reply #222 on: July 09, 2010, 01:45:27 am »

The doctors mastery of these codes makes my frightened.
Logged
[7:53:55 PM] Armok, why did you demand that I don't eat you?
[7:54:34 PM] [Armok]: woooooo

Burried Houses - Platform Explorer Demo H - Cloud Scream

ILikePie

  • Bay Watcher
  • Call me Ron
    • View Profile
Re: Programming Challenges & Resources (#bay12prog) Initiative
« Reply #223 on: July 09, 2010, 06:18:51 am »

Spoiler: original post (click to show/hide)

Edit: Never mind, rewrote both main and the canvas function to be more much more friendly with byte manipulation (Something I guess I would have done in the future). There are still a few hiccups, but it mostly works now, and very nicely too. Works flawlessly now. Here's the code if anyone cares.

On to my next question, can you give values to a struct's fields outside of a function? I have this:
Code: [Select]
struct RGB { blah blah blah...

RGB RGB_WHITE; RGB_WHITE.red = 255; RGB_WHITE.green = 255; RGB_WHITE.blue = 255;

int main(){ blah blah blah...
and I get "error: syntax error before '.' token".
« Last Edit: July 09, 2010, 07:57:15 am by ILikePie »
Logged

DrPizza

  • Bay Watcher
    • View Profile
    • Ars Technica
Re: Programming Challenges & Resources (#bay12prog) Initiative
« Reply #224 on: July 09, 2010, 09:53:06 am »

Quote
I'm trying to pass the pointer as an argument to function, and still keep the original struct's qualities. My code looks like this:
The brackets in my code were not superfluous, why have you omitted them?
Logged
Pages: 1 ... 13 14 [15] 16 17 ... 78