Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411283 Posts in 69325 Topics- by 58380 Members - Latest Member: bob1029

March 29, 2024, 06:40:13 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)The grumpy old programmer room
Pages: 1 ... 274 275 [276] 277 278 ... 295
Print
Author Topic: The grumpy old programmer room  (Read 733465 times)
ProgramGamer
Administrator
Level 10
******


aka Mireille


View Profile
« Reply #5500 on: October 12, 2017, 03:51:57 PM »

Can you not left shift by zero or am I missing something?

Edit: Oh wait you can't left shift a literal.

Edit 2: Nope, you totally can, I'm stumped.
« Last Edit: October 12, 2017, 03:57:46 PM by ProgramGamer » Logged

gimymblert
Level 10
*****


The archivest master, leader of all documents


View Profile
« Reply #5501 on: October 12, 2017, 05:09:00 PM »

What does the generated assembly looks like once compiled?
Logged

powly
Level 4
****



View Profile WWW
« Reply #5502 on: October 13, 2017, 04:49:41 AM »

To clarify: that’s GLSL, I’ll see if a trick to dump the intermediate language version from NV drivers still works and do an isolated test to see what the results are for some given inputs once I’m at my GPU.

Edit: a ha, it’s about shared memory visibility — seems like more care is needed when trying to equate CUDA and nv-glsl. The latter loop works with a shared memory barrier before the sum. The behavior is not guaranteed by the spec so it’s not strictly speaking a bug but it’s definitely not in line with the typical lockstep behavior (all the threads that execute this should be in the same lockstep unit, “warp” or “wave”). I’ll try the arb ballots next.
« Last Edit: October 13, 2017, 08:09:58 AM by powly » Logged
ferreiradaselva
Level 3
***



View Profile
« Reply #5503 on: October 15, 2017, 07:34:29 AM »

grumpy because undefined behavior accessing uninitialized variable. Lips Sealed

Forgot to set the Z of my "2D" vectors to 0, and sometimes the sprites would draw on the screen, sometimes not. The Z was sometimes outside of the depth range.
Logged

Photon
Level 4
****


View Profile
« Reply #5504 on: October 17, 2017, 08:58:20 AM »

Code:
ERR: TC_PathFollower.hx:67(stage.enemy.test.TC_PathFollower.testPathMiddle) - expected '50' but was '50'
Huh?
Logged
ferreiradaselva
Level 3
***



View Profile
« Reply #5505 on: October 17, 2017, 09:35:39 AM »

Float comparison?
Logged

Photon
Level 4
****


View Profile
« Reply #5506 on: October 17, 2017, 11:50:38 AM »

Float comparison?
Yup. For the longest time, I was pretty dodgy about using floats at all. I think I've already tracked down what's causing it, but its still annoying (albeit briefly humorous.)
Logged
ferreiradaselva
Level 3
***



View Profile
« Reply #5507 on: October 17, 2017, 12:36:15 PM »

Curious what are you using the comparison for?
Logged

Ordnas
Level 10
*****



View Profile WWW
« Reply #5508 on: October 17, 2017, 11:33:22 PM »

Curious what are you using the comparison for?

Was it probably written with a Logger that casts numbers to int? Funny ahah  Grin
Logged

Games:

Photon
Level 4
****


View Profile
« Reply #5509 on: October 18, 2017, 08:16:03 AM »

Curious what are you using the comparison for?
Its a unit test that is confirming expected values for a given outcome. Essentially, its an equality assertion.

The problem is fixed now, fyi.
Logged
ferreiradaselva
Level 3
***



View Profile
« Reply #5510 on: October 18, 2017, 10:06:25 AM »

lol, I was doing the same with my math library days ago: https://github.com/ferreiradaselva/mathc/blob/6dabf9f1d1d9db9623078a1537409106b2e25784/mathc.c#L50-L64

My grumpiness today is with perspective matrix. I fixed some problems with the perspective matrix (and it's working perfectly now). The problem is... I'm so bad at setting up a good FoV/far/near and camera position. I'm working on a example for my framework. I made this model on Blender especially for that:



I want to make it like a Sketchfab viewer, where you can drag/rotate and show the wires.

edit: I guess I'm understanding the FoV/far/near thing now.

edit 2: no I'm actually not. Everything gets cut too soon with the far clipping, even with large numbers. I *think* I have to scale down things.
« Last Edit: October 18, 2017, 11:50:43 AM by ferreiradaselva » Logged

powly
Level 4
****



View Profile WWW
« Reply #5511 on: October 18, 2017, 11:21:25 PM »

Sounds like a bug; scaling shouldn’t matter if you scale everything simultaneously. FOV is not directly related to the near/far plane distances but different FOVs might have different “reasonable” values for at least the near plane. The near and far planes only essentially manage the precision of your z-buffer so that most of the range is used for something sensible (stuff you want to z-order properly, i.e. without fighting)
Logged
WaywardEmcee
Level 0
***


View Profile
« Reply #5512 on: October 20, 2017, 03:03:48 PM »

Agree.

However, I think spending a little time up front engineering & a little time refactoring as you write = time saved exponentially = faster release.

At least for smaller scale projects, but I think this would scale at bigger projects too.

To repeat, I agree that Shipping is everything


This depends more on what kind of code you're writing. If you're doing systems programming and you have duplicated code you're adding a massive amount of maintenance overhead to any systems changes in the future. Sure you might get your game to shippable state faster, but if after some play testing a flaw in your system is revealed the fix could be extremely costly, especially if the fix doesn't solve the issue the first time around.

Mechanics level code is more forgivable in terms of duplication. Worst case scenario you'll have some inconsistent behavior here and there, but it's typically something more solvable with large Find/Replace.
Logged

Follow me on the twitters: @WaywardEmcee.
risen28
Level 0
**


View Profile WWW
« Reply #5513 on: October 21, 2017, 12:17:52 PM »

Will WordPress rule the world ? seriously whenever im looking at competition for my client , to assist me with their web design , everything is wp-themes. Should i just throw away laravel. I used to think It was frowned upon for web developers to use WordPress , i guess i was wrong.
Logged

If there is no enemy with , the enemy outside can do us no harm.
ThemsAllTook
Administrator
Level 10
******



View Profile WWW
« Reply #5514 on: October 23, 2017, 07:04:29 AM »

I just spent 40 minutes chasing down memory corruption caused by changing the type of a struct in an allocated array, but forgetting to update the struct type in my malloc(sizeof(struct) * count) invocation. This seems to be the most common cause of memory bugs in my code. I suppose I ought to get in the habit of allocating with sizeof(*variable) instead of sizeof(type)...
Logged

JWki
Level 4
****


View Profile
« Reply #5515 on: October 23, 2017, 04:59:42 PM »

I just spent 40 minutes chasing down memory corruption caused by changing the type of a struct in an allocated array, but forgetting to update the struct type in my malloc(sizeof(struct) * count) invocation. This seems to be the most common cause of memory bugs in my code. I suppose I ought to get in the habit of allocating with sizeof(*variable) instead of sizeof(type)...

I'm assuming C because in C++ you'd have to cast what malloc returns you to the correct type and hence not be able to forget to update that line
Logged
ferreiradaselva
Level 3
***



View Profile
« Reply #5516 on: October 23, 2017, 05:42:00 PM »

I just spent 40 minutes chasing down memory corruption caused by changing the type of a struct in an allocated array, but forgetting to update the struct type in my malloc(sizeof(struct) * count) invocation. This seems to be the most common cause of memory bugs in my code. I suppose I ought to get in the habit of allocating with sizeof(*variable) instead of sizeof(type)...

Did you swap the name of two structs to be able to still compile?

I like to use sizeof(type), but I see the problem with having to change the name everywhere in the code. However, nowadays I avoid dynamic allocation like plague.
Logged

ThemsAllTook
Administrator
Level 10
******



View Profile WWW
« Reply #5517 on: October 23, 2017, 09:52:57 PM »

Yup. I was adapting some old obj loader code I had around to work with the renderer I'm writing, which expects vertex data in a different format from what I was using back then. I changed to a different vertex struct type that has a few more attributes and filled them in with default values, but missed changing it in my malloc call, so my allocation came up short and started stomping on other stuff when I wrote to the second half of the memory block.

All good now. It's just annoying to realize how many times I've made this exact same mistake in some form.
Logged

Crimsontide
Level 5
*****


View Profile
« Reply #5518 on: October 23, 2017, 10:12:23 PM »

a rant on noexcept....

Over the past few months I've been trying to integrate noexcept into my C++ code.  On the surface this sort-of new feature looked decent.  For the record, even though I know C++ has its caveats I quite like it, and I am very 'pro' exceptions (pro/con pro, not pro as in I know everything).  I will (and have in the past) happily defend exceptions as a superior form of run-time error handling.  So noexcept should be right up my ally...

But no, in short noexcept is currently a mess and should be avoided...

The idea behind noexcept is that you can tag a function (member function, normal function, operator, whatever) as noexcept like:
Code:
void Func() noexcept { /*... do stuff here that doesn't throw an exception...*/ }
which declares to the compiler that the function does not throw an exeception.  The idea being that code can later choose a more optimal algorithm if you know a function doesn't throw.  You can test this with the noexcept operator:
Code:
noexcept(Func())

The thing is noexcept is much like const, it gets everywhere.  Once one function is tagged as noexcept, every function used in it needs to be noexcept (or nearly, as try/catch blocks can work around it), which then transitively propagates to any functions they call, and on and on...  Much like you just can't add one or two const's in a program and hope all goes well, similarly with noexcept.  Its either all-in or not-at-all.  Except things are even worse with noexcept.  const simply applies to types, classes, and their member functions.  noexcept applies to all functions, not just some functions.  Doing it 'right' and noexcept ends up everywhere.  Its starts cluttering code and getting everywhere.  I know its C++, and its not the nicest syntax, but still...

But then things start to get nasty, there's two really big problems that aren't immediately obvious.  The first is the noexcept operator and its interaction with templates.  As soon as you add templates into the mix, you don't know exactly what functions are being called, so you can't just look at the code and know 'ya that's a noexcept function' or 'no that function clearly throws'.  Maybe it throws, maybe it doesn't, depends on the template parameters.  So the idea is to test them with the noexcept operator.  The simple example online and in the docs are things like:
Code:
void FuncC() noexcept( noexcept(FuncA()) && noexcept(FuncB()) );
The above example would declare a function FuncC() noexcept if FuncA() and FuncB() are both noexcept.  So for simple function boiling down the logic to a simple state is possible if not a bit annoying.  But anything remotely complex, and you're ready to throw your computer out the window.  In many cases the noexcept specification becomes as complex, if not more so, than the code itself.  These things start to become monstrous, and trying to keep the code and specification cohesive while fixing bugs, making changes, refactoring... to say its a nightmare is an understatement, and completely intractable in all but the simplest of situations.  And of course, it'd be nice if we only had to do this on the odd function, but like I mentioned above, tag one function noexcept and it starts to spread like a plague through your code...

This is itself is annoying, but the last problem is insidious.  Unlike const, noexcept isn't checked at compile time.  So while const is annoying at first, at the very least its trivial to debug.  noexcept on the other hand is a nightmare, make a mistake and you don't get an easy to find compiler error pointing directly at the error, no you get some weird seg fault or stack corruption in some bizarre part of code...  Multiply this over an entire code base... and well...

/sigh

Now noexcept COULD be very good, something like it is very useful.  If noexcept was checked at compile time and the specifier was only used as a declaration (ie. you didn't need to specify noexcept for functions under normal circumstances, instead the compiler deduced it from static code analysis, and noexcept was only required when needed to override the default analysis, or in function pointer declarations, etc...) then it could be very useful.  But of course that doesn't work on 60000 year old machines running on 93 bit architectures with 4kb of ram that have no way to perform cross translation unit analysis.  So instead we get this half baked monstrosity.

For anyone who's gotten this far.  My suggestion would be to only use noexcept on move constructor/move operator, and otherwise forget it exists.

This is a warning for those who might wish to travel down the noexcept rabbit hole, there is nothing but darkness and insanity waiting for you...
Logged
oahda
Level 10
*****



View Profile
« Reply #5519 on: October 23, 2017, 10:41:44 PM »

According to what I've read, testing for noexcept would indicate misuse, because the noexcept marker is supposed to be part of the signature and be a promise to the API user who might write other code that depends on that function remaining noexcept; if you can't guarantee that the function will remain noexcept through updates you shouldn't mark it as such in the first place as far as I've understood. I only use it for simple functions that by design would not make sense to change that fundamentally in the future. I may be wrong tho. Panda
Logged

Pages: 1 ... 274 275 [276] 277 278 ... 295
Print
Jump to:  

Theme orange-lt created by panic