Why I no longer use fossil source control.

For many years I have used fossil as my source control of choice. It was my first source control and it was a revolution for me. So many projects I have completely fucked up by not using source control. Fossil is great, it solved all of the sticking points which caused me to resist using  other source controls such as git or whatever else was popular at the time. I really like its single file repository approach, all other source control have this massive folder of bullshit. I also love that the checkout is separate from the repository, seriously that is total bullshit. What if you want to work on two revisions at once, well you can’t.

Now fossil has one major issue which is not a problem at first but overtime it becomes a bigger and bigger problem. Absolutely no way to alter history at all. Now I am not a fan of re-basing or any other kind of altering history but fossil takes it to an extreme. Fuck up your last commit? Just realized one second after you hit enter? Well you are fucked that commit is there forever. Sure you could grovel through the undocumented database file and manually undo that commit but good luck with that.

Now lets talk about git. I really quite dislike git, its kind of shit. But git works and it has lots of momentum behind it. You also have places like github and gitlab where you can upload and share your repositories. Fossil basically has nothing, its too niche. Git has a terrible user interface and has no decent gui to speak-of. Even the web interface for github is absolute trash which is barely usable compared to the perfection that is the UI that comes built-in to fossil.

But even with all the advantages of fossil, I really just cannot use it anymore, not being able to undo your last commit is just too much to deal with. I am a scatterbrain, I use source control to help me organize my work and not completely destroy my project as has happened before. But not being able to undo a mistake I made just seconds ago is bullshit.

Another nice thing about git which I have come to realize is actually a good feature is the stage. Fossil does not have such a system, commit is just a single step in which you specify what files you want to commit and it is done. I have often forget to commit files and other times accidentally committed everything even stuff that I did not want to. The stage is really helpful in making sure you commit exactly what you intended to commit, and also allowed you to do so in stages and not just a single command which you can easily fuckup.

So in summary, I am sad that I have to stop using fossil its almost perfect but its issues are to large to deal with. I shall now enter under the suffering and bondage of that horrible master that is git. Fuck git.

 

 

 

 

Posted in Uncategorized | Leave a comment

Intel is fucking shit, absolute worthless garbage, fuck them and their worthless cpus.

So I was working on some existing code written in assembly and self-modifying. I was trying to reduce the amount of self-modifying code by replacing some self-modified immediates with register values where registers where available to hold said values. To my surprise after changing a shift instruction with immediate to CL, the code got significantly slower.

Now it took me quite a while to actually discover this, I had changed the function somewhat to free up the CL register for the shift length, I at first thought it was the combination of all the changes that had added together to result in the observed performance drop but after more experimentation it became clear is was all due to the shift instruction.

WHAT THE FUCK, THE SHIFT INSTRUCTION IS FUCKING SLOW. After checking Agner Fog’s instruction table I confirmed it. On sandy bridge and later the shift instruction with length in CL takes 2 CLOCK CYCLES. What the fuck where they thinking crippling such a common instruction, this instruction is 1/4 the speed of Nehalem, this is slower than every single x86 cpu going back to the Pentium (except P4, but we don’t talk about that). Its slower then fucking Bulldozer.

Intel are fucking retards, they are incapable of making cpus with consistent and predictable performance. Why would they do this, all code written for previous sane cpus is now crippled on this fucking garbage. This is just one of the many layers of bullshit that is the Intel cpu. I won’t even start on the disaster that is AVX and the SSE mode switch issue, seriously WTF. I read that with their newer cpus its even worse, apparently the AVX penalty is now payed for every single SSE instruction executed. If the AVX-512 resisters are dirty then cpu permanently fucking downclocks because each SSE instruction causes an implicit merge back into the full register.

This bullshit has gone too far, I demand Intel be nationalized and shut down. All executives and upper management shall be flayed alive. And any engineers responsible for this retarded bullshit shall be burn at the stake. At they very least all their bullshit x86 patents should be invalidated so that some competent companies can step up and give us some cpus that arn’t fucking Shite. AMD is looking pretty good at the moment but it would be nice to have some competition.

Instruction sets should not be patent-able, nothing in the x86 instruction set is new or novel. In fact its quite the opposite, most of the instructions Intel have come up with recently have been fucking awful garbage. But since so much software is using this crap you have to live with it. I think the x86 went horribly wrong with most of SSE and its gotten so much worse since then.

On the subject of bad instruction set design, I think Intel’s first mistake was back in 1997 with the MMX instruction set. This had the potential to be incredible, we could have had general purpose 64bit integer registers. I have almost never needed to use vector processing, but having native support for 64bit integers would have been a massive improvement especially if multiply and divide instructions where provided. Aside from the lack of 64bit integer instruction MMX made another massive mistake, a mistake which in my opinion was the reason MMX failed to gain real any real traction, MMX trashes the fpu state and required a complete reset after use.

Imagine what could have been if MMX could coexist with x87 and not require that expensive EMMS reset instruction. The compiler would have casual access to 64bit registers, if MMX had included some basic 64bit instructions such as add, sub, shifts, mul and div. That would have significantly sped up much code, as it is using 64bit int on x86 is horrible, especially so if one requires multiply and divide. It would also have been possible to mix fpu and mmx simultaneously. It would have still been possible to share the same registers for both mmx and x87, just don’t mark the x87 registers as in-use when mmx is used on those registers.

 

 

 

 

 

 

 

 

 

 

Posted in Uncategorized | Leave a comment

The exe-modifier.

For many years I have worked on the insanity which is my exe-modifier. This insane piece of software is basically a linker which can insert objects into an existing executable. This allows one to make extensive changes to an existing binary and implement whole new functionality and features. This new code can be written in c/c++ and closely integrated into the existing code.

There is little documentation on how to use this software and only a handful of example projects, the source code includes two examples, neither of which use even a fraction of all the features this software has haphazardly grown over the years. If anyone actually has any interest in using this abomination I am willing to assist them into getting started with the garbage. I will write some docs in the rare case that anyone takes interest.

Example, the music calculator.
This is a fun example which reveals the power of the exe-modifier.
I have taken the standard windows calculator and modified it to implement a rotating sine-bow behind the buttons and to play music from an embedded module file.  The code for this example can be found in the exe-modifier source code as “example2”. I have always been exceedingly pleased with this example, as well as being a great example for the exe modifier, its also the only demo like thing I have ever made.

music-calculator

music_calc.exe
exe modifier release on github

The music featured in the example:
happiness_island.mod, by Bernard Sumner, 1993

 

Posted in Uncategorized | Leave a comment

Fuck the c++ standards committee, they are a bunch of fucking retards. C++ needs to be forked.

So today I was doing some coding and was greeted with this message: “reference to ‘byte’ is ambiguous”. Of course I was very confused but after a close examination of the error message I noticed this: “candidates are: ‘enum class std::byte'”

What the Jesus living fuck. You retards decided decided that you would take the very common name ‘byte’ and use it for this enum thing. I know that its part of the std:: namespace which is owned by STL but seriously, its not uncommon for using namespace std; to be found somewhere in a code base along with typedef unsigned char byte;”.

Apparently std::byte is related to some type-safe bullshit that no-one ever asked for,  the c++ standards committee keeps adding worthless features which do nothing to address the issues real programmers have and hardly ever add anything that is actually useful.

Over the yearsC++ has irritated me more and more, only a handful of changes to the standard in C++11 and newer have actually been useful, its mostly just worthless bullshit whilst the big issues are never addressed. I propose we fork the c++ standard and create a new standards committee formed of people who actually want to get work done and not just masturbate over some type-safe correctness bullshit.

 

Posted in Uncategorized | Leave a comment

GCC-9, those retards finally fixed something for once!!!

So I was just checking out the new gcc-9 release and I discovered something to my surprise. They have done something exceedingly rare, they have actually fixed one of their many insane long-standing code-gen bugs which have caused me major aggravation for years.

This particular bug was introduced in gcc 4.8 (according to compiler explorer). The specifics of this bug relates to the use of post-increment when dereferencing a pointer. The compiler in its infinite insanity would perform the increment before reading the value at the pointer address.

char ch = *p++;               // as part of a loop
incl	%ecx                  // generated assembly
movb	-1(%ecx), %al         // seriously WTF

GCC-9 appears to have finally have fixed this, the increment now happens after the memory read, as it should. How the hell did this bug last for so long without any complaints as far as I could find. Am I the only one who ever actually looks at the generated assembly.

 

 

Posted in Uncategorized | Leave a comment

Sonic hack, super fast sonic

I have created a small sonic hack that massively increases Sonic’s running speed. I know this had been done to death however my hack has a feature I have not seen in previous speed hacks. My hack increases the scrolling speed such that the screen can now keep up with the massively over-speeded sonic. This hack uses the same optimizations as the previously released TAS player. On Tool Assisted Speed Runs and the playback thereof

Hack features.
1. screen scrolling limit increased 4x (64 pixels per frame)
2. running speed increased 5x (30 pixels per frame)
3. acceleration increased as well
4. made special stages faster
5. made a few objects move faster

super-fast-sonic.zip
source code – github

 

 

 

 

Posted in Uncategorized | Leave a comment

Vgm Player V3.42 released

I have just released a new version of the vgm player, V3.42. It fixes a serious bug that I missed with the previous version. Also adds support for V1.61 and V1.70 vgm files.

The bug was this: writing misaligned data to the rom. It turns out that the emulator I use for testing allows reading of misaligned data (Kega Fusion). This emulation inaccuracy is not a bug, it is  performance optimization. Original software would never perform misaligned reads as it is a fatal error, so there is no need to pay the cost to emulate it.

When one forgoes real hardware testing one shall get bitten eventually.

VGM_PLAY V3.42

 

 

 

 

 

Posted in Uncategorized | 1 Comment

On running dos executables on x64

Well it became necessary to make updates to one of my old projects, the Vgm player. And that happens to be built with a dos application SNASM68K. At this point I have fully migrated over to 64bits so this presented a small issue. How to run this application which Microsoft in their infinite retardation decided to no longer support. Their excuse; that amd64 lacks support for V86; is utter bullshit, I know for a fact that the Ntvdm code base supports x86 emulation.

Anyway I needed to run this application, one simple way would have been to use a VM but that is kind of shitty and inconvenient. There is an existing solution,  NTVDMx64 by Leecher1337. This is an x64 build of the official Ntvdm built from the leaked windows NT4 source code. I did not use this for two reasons, 1: its does not support xp/2k3. 2: I dislike how invasive the patch is to integrate it into CreateProcess, also it would have been significant work to adapt the patch for xp/2k3.

Another option. Reactos Ntvdm , this recreation of Ntvdm works on XP/2K3 and can be built in a standalone mode so does not require the invasive integration into CreateProcess. The disadvantage however is that without the CreateProcess integration one cannot start the dos executables in the normal way, all callers would need to be modified to start the dos application by proxy of ntvdm.exe

The solution: I really do not need system wide support for dos applications, I really only have one or two dos apps which I cannot replace, so why not just build ntvdm into each dos application, so that is what I did.  I have the modified the Reactos Ntvdm to load the dos application appended onto the end of the Ntvdm binary. This creates standalone x64 compliant dos applications.

dosEx64.exe – dos executable patcher
SNASM68K.exe – 64bit compatible

 

 

Posted in Uncategorized | Leave a comment

Fixing the XP/2K3 calculator paste delay

The paste functionality in the classic windows calculator is implemented by generating button presses, as defined by the paste text. In windows 2000 and before these button presses can be seen. In XP this visual feedback was removed, the corresponding delay however, remains. This delay can be aggravating, especially when doing heavy calculations, after years of suffering this inconvenience I finally snapped and resolved to do something about it.

Fixing: To locate the relevant code I first located calls to GetClipboardData, of which there was one. The nearby loop which parsed the clipboard string contained no delays and simply forwarded the characters elsewhere by sending WM_COMMAND to some other window. With that avenue failing to bare fruit I instead located calls to the Sleep function, I found a single call which happened to be the offending code. The call to sleep was a fixed 20ms sandwiched in-between two calls to SendMessageW with BM_SETSTATE. I changed the delay to 0ms and the horrible delay was gone.

the code of interest

Patched calc.exe for windows 2003 x64: no-delay-paste-calc.zip

Posted in Uncategorized | Leave a comment

On Tool Assisted Speed Runs and the playback thereof

The standard way to watch a tool assisted speed-run is via a pre-recorded video. This sucks, not only are you having to download a very large video file, but the quality of said file, even when bit-rates are high will still be very substandard. The other option for watching is to download the specific game rom, emulator, and button press file. This is just inconvenient, as you have to trawl all over the internet to locate required pieces.

As the options discussed previously were unacceptable, a new solution was needed. The solution that was found was to bake the button press data into a modified version of the rom, the tool assisted speed run would then run like a built-in demo. This procedure is very game specific and may not even be possible for all games depending on how complex their lag behavior is, the game I have used is the MegaDrive game Sonic 1.

De-synchronization and lag frames

The main issue facing tool assisted speed-runs is desync due to the difference in timing between various emulators and the real hardware. The main cause of this desync (in the case of Gens-rerecording) is the fact that the emulator records controller input synchronous to the display frames, this means a single mismatched lag frame will cause all subsequent controller input to be desyned.

The other and much more insidious cause is the fact that (in the case of Sonic1) during the execution of the game engine the interrupts are left enabled, this is such that if a lag frame occurs, the music (sonic 1 uses main cpu for music) and palette (LZ water), will continue to update. There is another unfortunate side effect however, the frame counter is incremented in the vertical interrupt handler. This counter is the timing source for many in-game effects some of which effect the game-play such that desync can occur.

Solutions to desync

The main cause of desync is simple to correct, instead of recording the controller state on each display frame one shall instead record the actual controller state read by the game code. With this method of recording, lag shall no-longer cause controller desync.

The solution for the secondary cause is not so simple. The value of the frame timer is critical, even being off by 1 can significantly change the behavior of the game. There is no way to model the value of this variable as it is linked to the lag frames and thus the specific timing of the recording emulator. The only solution is to record its exact value for each frame.

Implementation – Controller Data

The controller data consists of two bytes for each event, the first being the timer increment and the second being the controller state. To perform the conversion of controller data it was necessary to modify the gens-rerecording emulator, specifically controller reads and frame timer reads were hooked, each controller read is considered the start/end of an event, reads to the frame timer are noted and used to determine the timer increment for each event.

Implementation – Sonic 1

The Sonic 1 game was modified to playback the converted controller data, the controller read function was modified to read from the controller data. The increment of the frame timer was removed from the vertical interrupt handler, instead the frame timer is updated explicitly in the controller read routine, its value increased by the amount specified in the timer increment byte of the controller event.

Sonic1 speed-runs exploit glitches in the game to achieve insane speeds and often skip entire levels all together. The in-game camera however is limited to just 16 pixels per frame scrolling. With this limitation much of the TAS video is that of just scrolling. To correct this I removed the scroll speed limit from the game, the camera shall now stay centered on sonic no matter how fast he moves. Specifically I increased the scrolling speed to 32px left and 64px right. If sonic moves faster than this such as wrapping to the end of the level then the entire screen is reloaded.

One would think such drastic changes to the game would cause desync, but having corrected the lag frame issues I can now make major changes without causing a desync. Any reader who understands the Sonic1 engine would wonder how removing the camera position limit did not result in desync as the game objects are effected by screen position. Well I simply duplicated the screen position variables, the original 16 pixel limit is still used internally to keep the engine happy.

One might also think that all these changes would cause massive slowdowns, what with the checking of two screen positions, particularly with the sprites, which have to be drawn with one  screen position but have their onscreen bit set using another. And the doubled, or quadrupled scroll speed. But actually the slowdown is about the same of maybe even a bit less! This is because some of the existing code in sonic1 is slow as fuck, I made many optimizations both major and minor, particularly the horizontal scroll, I can update 64 pixels about the same speed as the game used to mange 16.

Converted runs

Sonic The Hedgehog (W,) (REV 01) [!]Aglar.zip
Sonic The Hedgehog (W,) (REV 01) [!]no_zips_Aglar.zip
source code – github

I would really like to do other sonic games as well but this really took to long, and also the newer sonic games being much more complicated will likely have more serious issues that may or may not be solvable.

Posted in Uncategorized | Leave a comment