I am getting warnings (treated as errors with compiler settings) for conversions from uint64 to size_t anywhere that 'TotalSize' (in the win32_state struct) is used, and for a signed/unsigned mismatch when evaluating the int/size_t comparisons during the for loops within CatStrings()

The code in question are the lines:



and then



I have verified that my code is correct, and also downloaded the source code to compile an unedited version of Casey's .cpp and .h files, which produce the same result.

I tried using casting, for example:


and



which allowed me to successfully build the executable, which in turn successfully built the .dll, _temp.dll and all four .hmi files, which are the correct file size, however the looping behaviour does not seem to work.

Pressing L does not activate the recording feature, which is evident as further presses do not restore the state and activate the 'loop'

I have tested all other functionality which works as usual, and the looping was working previously (after Episode 24) when the function was writing to disk. I am confused as to why this is happening, especially after directly compiling the downloaded source, and can't seem to figure it out; is anybody more experienced than myself able to shed any light?

My system has an Intel Core i7 4820k, with 16gb RAM and is running Windows 7 64bit. I am compiling with cl via batch file, using the correct VS. The only variation is that I code with Sublime 3 instead of emacs, but I can't see that making any difference. Any help would be appreciated!

I cannot help you with the loop problem itself but two things did catch my eye.

uint64 and size_t are both defined with 'typedef unsigned __int64' so I'm not sure how there is any problems with cast (I am using the size_t definition from crtdefs.h and the uint64 from basetsd.h).

As for your int/size_t problem, my suggestion would be to change int Index in the for loop to unsigned as that is 'more correct' (Index shouldn't be negative in this case). So it would look like:

Thanks for replying. That was how I originally tried to 'fix' my problem, but ended up casting as it was basically the same solution as in the other section. Thanks for pointing out your reasoning for taking the other approach, if that produces a better or more accurate loop I'll make sure to change it :]

Mostly I am confused as to why the behaviour is different. Is it something about my system that is understanding 'int' to default differently? This is the first time I've had an issue that has not been present during the streams where the code is identical. I'm also not sure why, after changing the values to compile correctly, the recording and playback functions don't seem to work. I would like to fix the issue (or more accurately, to understand why it is happening) knowing that it is behaving as intended so that I don't simply hide a deeper problem that might surface later in the project, when it will be much harder to find.

Maybe I'll try to catch the stream on Monday and ask Casey in the QA section

For my it was the 32bit vs the 64bit compiler

size_t on 64 bit is same as int but on 32 its unsigned or something (maybe other way around)

it could be which works on both versions of compiler



btw your cast also works on both versions...

Yes, based on your description I would say you are compiling in 32-bit windows which is not going to give you enough memory to allocate the live looping buffers, so the code then (correctly) avoids crashing by simply if()'ing around the code that actually does the loop save/restore.

The way you can tell this is because of the warnings you were getting for uint64 vs. size_t. If size_t is not the same size as uint64, the compiler warns you off the loss of data, but the only way they would not be the same size is if size_t is 32-bit. If size_t is 64-bit, then they would be the same size.

size_t is (more or less) defined to be the integer size that can hold the maximum size of a memory block, so if it's 32-bit, then you know you're in a 32-bit memory space.

- Casey

Not quite sure what happened, but I had a somewhat similar problem with input playback not working. It was working fine for me until you added the if/else block in Win32ProcessPendingMessages() for the 'L' key to check if State->InputPlayingIndex == 0 before doing the begin/end recording work, otherwise calling Win32EndInputPlayback().

When I started recording it would work the first time, ending recording and looping input playback when I hit 'L' the second time, but if I tried to start a new recording loop and hit 'L' again to end and loop it would only restore the state and not the input. Subsequent attempts would continue to only restore the state from when I began a recording but would not play back the input. I then swapped my win32_handmade.cpp for yours and rebuilt and the same thing happened. When I deleted everything out of the w:\build directory and rebuilt it magically started working again, even after I put my code back in and rebuilt. Maybe a user error somewhere in there, but I can't imagine where. It seems like somehow it wasn't overwriting or properly loading loop_edit_1_input.hmi after that first code change I mentioned until I deleted it, although that doesn't make sense since it would properly record and replay the first recording loops input, just not subsequent recording loop inputs.

I'm building in 64-bit mode, so again not really related to OP's problem, just to the topic :)

EDIT: and yes, my Win32GetInputFileLocation() definition and calls from Win32BeginRecordingInput() and Win32BeginInputPlayback() are the same as Caseys, so not a bug there.