« first day (2972 days earlier)      last day (2052 days later) » 

12:23 AM
@Kay :P Reminds me of how long it took me to get to the end of Morrowind :P
 
 
15 hours later…
3:35 PM
Morning!
 
user92578
hey!
 
@Tyyppi_77 It's Monday, are you having a day off?
 
user92578
no, it's free time already
 
user92578
I've been brining my laptop with me for a few weeks now, doing some light programming in the evenings when I've felt like it
 
Oh, ok, cool!
Working on GH or it's too much involved for the time you have?
 
user92578
3:40 PM
yeah GH stuff, but very small stuff on it
 
user92578
definitely don't want to get onto larger features or such, just small polish, like I started with the text selection stuff here and finished at home
 
user92578
now I'm fighting with C++ & utf stuff
 
user92578
tbh I didn't realize this was going to be an issue since my Finnish localizations load in just fine, but getting text input from SDL is a whole different deal
 
user92578
so SDL gives me "ä" when I type "ä"
 
That's interesting! Aren't there libraries that exist for such things?
 
user92578
3:48 PM
Probably, I'm trying to find one that's lightweight enough
 
user92578
It's actually sort of disappointing that SDL doesn't have anything to help with this
 
user92578
lol, so looks like I can force my text renderer to decode while rendering, so it renders properly, but text editing is of course broken since two characters render as one
 
user92578
I'm starting to understand why people are always bitching about unicode stuff
 
yeah, unicode sort of has to do away with the concept of a character, and instead just has “code points” which may be graphemes or joiners or all kinds of stuff.
 
user92578
yeah
 
user92578
3:58 PM
sort of odd that it can represent utf stuff as a single character just fine if it comes from a file
 
I'd add some kind of thing that takes care of the accidental selection of an option right after dying
It's currently the most annoying thing in the game, in my opinon. IT'S STILL LOTS OF FUN. Just an annoyance. :)
 
user92578
Yeah that's a great idea, I already tried to do that a few times but those approaches have not worked
 
user92578
Like just a naive delay before accepting input is no good, since that prevents fast respawning
 
user92578
Maybe like disabling just the quit button for a moment?
 
user92578
Just read my first message there and realized that it sounds sarcastic
 
user92578
4:08 PM
that's totally not what I meant, I really do want to fix that
 
user92578
So this is probably far from a proper solution, and I still might look into proper UTF libraries in the future, but I think this'll do for now
 
user92578
std::wstring_convert<std::codecvt_utf8<char>, char> converter;
const auto& result = converter.from_bytes(text);
 
5:06 PM
yeah I knew what you meant
:)
I think the core issue is that shoot is the select button.
and if you die on a ladder, you're probably pushing up or down
I can't say how to solve this
other than to check games like Meat boy and see how they do it
I don't recall haviung that issue with meatboy
 
5:25 PM
Cognizer does a game over that must last a certain amount of time.
even 1 second is probably enough
 
5:44 PM
@DMGregory Great floating point answer. I added 1 to your mantissa figures due to the implicit bit. it's effectively 2^24 bits of precision and *2^-25 error.

Technically, (2^24)+1 range of precision because 2^25 can also be stored exactly too (last integer you can store without loss) but I wasn't gonna go into that much detail :)
@Tyyppi_77 Unicode is great to work around swear word filters among all the problems it causes :D
@Almo @Tyyppi_77 use a keypress event rather than a keydown state, ignore key repeats until you get an initial keypress?
 
won't help
you may be mashing the button
if so, you're still going to do multiple key events before you realize it's over
death comes VERY suddenly in that game.
 
okay, definitely needs a 1 or 2 seconds cooldown delay then.
 
it's a klunky solution, but might be the best
 
5:59 PM
games usually hide it in a death animation and/or fade-in of the UI menu
 
@StephaneHockenhull Maybe I got the math wrong, but I thought that since the 24th bit is fixed at one (ignoring denormalized numbers for now), it's still 2^23 distinct representable values in the range [2^n, 2^(n+1))
ie. every possible toggle of the 23 explicit bits we have.
 
You can represent integers 0 to 2^25 exactly (inclusive)
 
 
or put differently: if you got 2^24 stored you can still add 1 just fine
It's only when you got 2^25 stored that you can't add 1, you have to add 2
 
Hmm.. that seems to disagree with these answers, doesn't it?
https://stackoverflow.com/q/3793838/3064164
I'll write a little test script later to triple-check. I find I make off-by-one errors pretty easily when working it out in my head. ;)
 
6:08 PM
no, you're right. 2^23 stored you can still add 1
that's why it's 24bits of precision
So it's ` we have 2^24 representable numbers, spaced 2n−24 apart.`
Not 2^23 numbers
I was one too high here in the chat :P
you were one too low in your answer...
darn float implicit bit is confusing
I'm trying to figure out if it's 2^-24 error or 2^-25 error...
I think it's 2^-24 error
 
I think we might be talking about two different counts, actually.
 
Or rather, it's +/- 2^-25 error
 
For a given exponent, I can represent numbers between 1.000(23 zeroes) * 2^n and 1.111(23 ones) * 2^n, correct?
 
ooooh okay. put that way yes
 
So, how many numbers are there in that range, without changing any of the exponent or sign bits? Well, we have 23 digits that can each take on a value of 0 or 1 independently, so that's 2^23 distinct values in the range [2^n, 2^(n+1)), correct? (Note that it's a half-open interval with the endpoint excluded.
Yeah, that's the count I was talking about. I might just need to adjust the phrasing so that's more clear.
 
6:17 PM
Now that I re-read it, your numbers were right.
I'm used to think of it in equivalent fixed-points precision for a given distance unit rather than a given exponent.
 
That's also a useful measure. Maybe I should edit the answer to describe it both ways - some folks might find one more intuitive than the other.
 
Because usually the [ smallest unit value of concern ] scale is what matters the most in practical terms. Even though in practice it gets a lot worse due to other rounding.
Like, if I made a 2D game with at least 8bit of pixel fractions (like old 8bit/16bit games used in their physics) I could walk 65536 pixels either directions before I don't have those 1/256th of a pixel anymore.
 
Yeah - I find I keep referring back to this table again and again to work out just how much precision I have in a particular range / how far I can go before I lose it: gamedev.stackexchange.com/questions/75537/…
 
6:34 PM
I usually just do my physics in fixed points. Only doing the square root in float after subtracting in fixed points.
waaaaait...
`16 777 216 - 33 554 432 2^0 = 1`
I think the table is off by one. when you reach 16 777 216 you can't add 1 anymore, gotta add 2... or am I confused again?
 
7:04 PM
@DMGregory Are you editing your answer? I'm going to revert my changes if you're not mid-edit.
 
@StephaneHockenhull Thanks for checking. I'll wait until after work, so feel free to go ahead.
 
Kay
8:04 PM
@AlexandreVaillancourt how long did it take you to get to the end of morrorwind
 
@Kay I don't remember exactly. At least 5 years. I had to restart the game twice because I had stopped playing for so long that I forgot what I was doing.
 
#JustElderScrollsThings
 
Yeah, that's what I gather. I did not touch the other Elder Scrolls games because of lack of this :P.
 

« first day (2972 days earlier)      last day (2052 days later) »