Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

891028 Posts in 33520 Topics- by 24763 Members - Latest Member: skeevs

June 18, 2013, 05:22:52 PM
TIGSource ForumsDeveloperTechnical (Moderators: Glaiel-Gamer, ThemsAllTook)The grumpy old programmer room
Pages: 1 ... 168 169 [170] 171 172 ... 279
Print
Author Topic: The grumpy old programmer room  (Read 314154 times)
wademcgillis
Guest
« Reply #2535 on: August 05, 2011, 06:27:59 PM »

Take a look at pugixml Wink

Hey you! Thanks! Hand Thumbs Up Right
Logged
Trevor Dunbar
Level 10
*****


Working on unannouned fighting game.


View Profile Email
« Reply #2536 on: August 05, 2011, 06:35:05 PM »

Flash CS5 and CS5.5 will not embed ANY files listed in metadata tags.

This makes both releases FUCKING USELESS.

Man, what's up with everything Adobe getting their hands onto turning into flaming dog feces? It's like the opposite of the Midas Touch. Kind of like Electronic Arts in a way.
Logged

Toucantastic.
st33d
Guest
« Reply #2537 on: August 06, 2011, 04:59:24 AM »

(FYI, the limit is around 200 - including Flash's own classes, anything in the library, SWCs and your entire code base.)

... well a workaround: embed a SWF which has the classes over the limit, and getDefinitionByName them out of it?

It'll take a while to unhook a load of class references from the graphics and list them as Strings, but I believe you're right.

I'm uncertain whether the compiler may just load the class list from the SWF as soon as it sees it though. It would be nice if it didn't. (I certainly don't want to start having external files just yet - it makes it harder to distribute.)

I'll try to figure out a benchtest...
Logged
rivon
Level 10
*****



View Profile
« Reply #2538 on: August 06, 2011, 05:35:08 AM »

Oh god, I hate Windows programming...

Also, why is that windows command line so idiotic...
Logged
Glaiel-Gamer
Moderator
Level 10
******


Stoleurface!


View Profile WWW Email
« Reply #2539 on: August 06, 2011, 03:03:21 PM »

also: past me is a dick

here's 3 lines of code from a file that's probably ~8 months old

Code:
//if stuff:
...
shimmers[i].speed.y *= 0.98488578;
shimmers[i].speed.x *= 0.994987437;
...
...
...
//else
...
shimmers[i].speed.setLength(shimmers[i].speed.length()*1.02469508);
...

those numbers.... they mean something... but I don't remember what, or how they're derived... and there's no comments about them

the rest of the numbers in this file are more normal, so its not like i went "I want to speed this up by 5% what's the new version of *.99 *.98 and *1.0"

Doesnt matter much, would just be nice to know wtf i was thinking

lol i found out how i got these numbers

Code:
0.97 ^ .5 = 0.98488578
0.99 ^ .5 = 0.994987437
1.05 ^ .5 = 1.02469508

must have wanted to halve the speed manually
Logged

mcc
Level 10
*****


glitch


View Profile WWW Email
« Reply #2540 on: August 08, 2011, 01:03:03 AM »

Okay... this is... one hell of a Heisenbug.

Background:

- There is a class A.
- There is a class B : A with a field "color".
- There is a virtual method B::draw() which runs some time after the object is created, which reads "color". It works.
- But then I add a new data member to A, an object. Abruptly, B::draw() stops working, when it reads "color" it shows strange values usually equal to 0. The result is the left half of the screen here, which is supposed to be a field of cyan:



So, the heisenbug! I look at this and go: Ok, lots of ways this could happen, memory corruption, whatever. So I try adding some printfs to right after B b = new B(); is allocated:

- I print b->color. It prints out as the correct color.
- I call a method B::alrg(), a virtual method with its method body in one of my cpp files. It prints out as the correct color.
- I call a method B::blrg(), a virtual method with its method body in the header file. It prints out a crazy incorrect color that looks like the "mostly 0s" in the image above.
- I call a method B::clrg(), a nonvirtual method with its method body in the header file. It prints out as the correct color.

What on earth

Increasingly starting to feel conscious of exactly how much of the time I spend writing C++ software, I spend debugging problems like this.

EDIT: ...I change draw(), instead of reading this->color directly, to call this->rightcolor(), a method which returns color and whose body lives in a different file. Suddenly it draws correct colors. Working out elaborate conspiracy theories in my head where draw() is getting inlined when it's called (should be impossible?) and that the common element to the methods on B which misread the color field is that they're inlined... this sounds like nonsense.

I want to take one of the minor workarounds I've found and settle for that, but I'm terrified this bug is going to rear its head in a more destructive manner later.
« Last Edit: August 08, 2011, 01:21:53 AM by mcc » Logged

My projects:<br />Games: Jumpman Retro-futuristic platforming iJumpman iPhone version Drumcircle PC+smartphone music toy<br />More: RUN HELLO
_Tommo_
Level 7
**


frn frn frn


View Profile WWW
« Reply #2541 on: August 08, 2011, 01:32:57 AM »

Wow, now that's a bug. Recompile?  Droop

Probabily you've stumbled on a compiler bug, looks like it is not generating the same data structure for your class in any compilation unit... but it is really strange that it works on *any *cpps but not on headers, as h's *are* cpps, in the end.
Looks like it can find somewhere an older copy of the declaration of your class, one that by include order is compiled just before your headers?
Logged

Nix
Level 10
*****



View Profile
« Reply #2542 on: August 08, 2011, 07:06:46 AM »

If it is fixed by rebuilding everything, you might think about getting a build system (besides a simple Makefile) that automatically detects header dependencies to avoid that kind of problem. Cellulose recommended Scons to me, and I really like it.
Logged
rivon
Level 10
*****



View Profile
« Reply #2543 on: August 08, 2011, 07:48:45 AM »

Or use Codeblocks which handles the building all by itself...
Logged
mcc
Level 10
*****


glitch


View Profile WWW Email
« Reply #2544 on: August 08, 2011, 08:53:51 AM »

Looks like it can find somewhere an older copy of the declaration of your class, one that by include order is compiled just before your headers?

I

...oh, shit

This comment actually caused me to find the problem

The problem turned out to have to do with a #define which should have been visible everywhere, but in fact was visible from some files but not others

This meant a certain type was considered larger in some files than in others, which mean different files were finding fields at different offsets

Ugh ugh ugh
Logged

My projects:<br />Games: Jumpman Retro-futuristic platforming iJumpman iPhone version Drumcircle PC+smartphone music toy<br />More: RUN HELLO
drChengele
Level 2
**


if (status = UNDER_ATTACK) launch_nukes();


View Profile Email
« Reply #2545 on: August 08, 2011, 10:11:54 AM »

...oh, shit
See, this kind of bug right here is why I gave up on C++ as my primary language. My grumpiness index has reduced by a few orders of magnitude since then. I still use it where necessary, but for my own projects/prototypes I've switched to managed languages and even (blasphemy!) game engines.

Don't get me wrong, I am not trying to start a language war here. There are many people who have the necessary discipline, experience and willpower to keep up with the C and C++ header/linker architecture and all its little wrinkles, and who like the overall control these languages give them.

But man, I have learned the hard way that I am not one of them.
Logged

Praetor
Currently working on : tactical battles.
rivon
Level 10
*****



View Profile
« Reply #2546 on: August 08, 2011, 12:41:20 PM »

I have these two classes:
CEntity
CPlayerChar which inherits from CEntity

When I try to compile it, GCC throws this error:
Code:
CPlayerChar.h:12: error: invalid use of incomplete type ‘struct CEntity’
CPlayerChar.h:9: error: forward declaration of ‘struct CEntity’

That forward declaration on line 9
Code:
class CEntity;
needs to be there because otherwise GCC throws this:
Code:
CPlayerChar.h:12: error: expected class-name before ‘{’ token

Does anyone know where's the problem? Clearly, CEntity is not a struct but class and the forward declaration has to be there.
Logged
BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #2547 on: August 08, 2011, 01:22:41 PM »

You shouldn't need a forward declaration, considering you are including the actual header file. I looks like it is misparsing everything, probably from some trivial syntax error.

You should instruct your compiler to output the source after pre-processing, and examine the lines immediately before the first error. See if you can spot something. Also keep an eye out for circular includes, or #define class struct.
Logged
rivon
Level 10
*****



View Profile
« Reply #2548 on: August 08, 2011, 02:06:47 PM »

It's solved now, someone on Stackoverflow pointed me in the right direction.
Logged
TobiasW
Level 7
**


This can only end brilliantly!


View Profile WWW Email
« Reply #2549 on: August 08, 2011, 02:47:56 PM »

So... will you tell us the solution to the riddle too?
Logged

Pages: 1 ... 168 169 [170] 171 172 ... 279
Print
Jump to:  

Theme orange-lt created by panic