Catacurses V2

As some of you may or may or may not know, I wrote the original library that allowed a seamless port to windows. It was for the original Cataclysm, and was meant to be a proof of concept thing. I expected someone to take it and build their own port of it. It was never meant to be front and center, but I’m glad it has become so. It’s the first time any work I’ve done has become something that actually has some value to it. I’ve licensed it under a plain zlib license (some text at the top of one header file, and maybe a single line at the top of some source files, telling that the license is in the header). This is NOT AT ALL to limit DDA’s access to it, but to separate it from being an actual asset of DDA, and to not have any problems in the future, as I’m working on releasing the source as a stand-alone drop-in replacement for other linux rougelikes/ncurses applications. I’m perfectly willing to work with kevin or whoever on that issue to do what I need to make it as smooth as possible. It will keep the name Catacurses as a tribute to the game that spawned it, and will (eventually) be available at

I’d like the help of someone willing to help me integrate the new version into DDA, as I’ve no experience with git/anything of the like. I still play the game when I have time, but I’ve gotten so used to playing with my console version that I’d like it to be merged simply so I can upgrade versions without having to compile it myself. Now, on to explaining this release a little.

To shine a little light on the performance complaints, it seeemed to me that the ‘default’ windows release was the old catacurse version, rather than the SDL version. I’ve looked over it and it’s been hacked to bits to allow the new wide strings. The new version (non-SDL) blows the current catacurse and SDL both far out of the water.

A major reason SDL seemed so much faster, is that rather than a 25ms timer on movement, it was a 1ms, so essentially it ran 25 times faster. I’ve changed this in the new catacurse so it will act faster as well. What people are calling performance, isn’t actually performance for the most part, it’s just sleep timers. But for real, actual performance, the old version uses GDI, or Graphics Device Interface, which a in-built windows library for handling graphics. So it looks and acts like a console, but is actually a 2D graphics engine that pretends to be one, which isn’t ideal.

A major advancement in the new version, is that it uses a true console window. I’ve made sure it supports XP and up, and after a few days of tweaking it’s very nearly complete. Not having an XP machine has slowed me down a little, as there were some gotcha for XP. The performance of a true console window will be very hard, if not impossible, to ever beat. It’s a core part of the OS, and is meant to be very very fast. It also makes the code much easier to follow, as there are less work-arounds to make it look more like a console, so if you guys ever wish to modify it more, it should be easier to do. Besides using a console window, I’ve went back and re-wrote several functions to perform better. Rather than printing one character at a time for a string, it now prints the whole line. Most all multi-character writes are direct memcpys and memsets directly to the buffer, so that alone improves performance a good deal on all machines. The only downside of using a real console, is that there is a little annoyance when you want to use custom fonts in a console window. I can write a stand-alone tool to help that a little (Optional download), but for most systems you’ll be limited to 2 or 3 fonts. I have it currently set to use the “Lucida Console” font, as it’s available on all sysems XP and up, and has a unicode variant to it as well, which brings us to…

Using a real console window had an unintended bonus, full Unicode support out of the box! Because windows is a multilingual OS, it should support all fonts directly on the console window, with no tweaks needed to accommodate them. This also means support for non-Latin languages such as Chinese, though wider characters may cause issues, but I’m not sure on that front. The only thing that has to be done to the game to get this working, is for the game to switch to using wchar_t as the main string type, which I believe Kevin already said they were going to do, so the newly formed catacursesw library will function with that just dandy.

As for the eventual tileset/SDL/etc version, I’m going back and adding some extensions and exposing a few properties to the logic so people can create other engines with it, whilst still using methods of emulating curses, leaving it up to them how to display the data. I don’t know much about SDL, so I’m afraid someone else will have to be responsible for making any changes to fit in with the new curses. I actually have a half-working version of a DirectX based version of my original curses library somewhere, so I may eventually offer a version of that, but don’t hold out for that. I’d happily work with anyone that wants to make their own display for catacurse, including the person that created the SDL port.

Any comments or requests for the new version should really be posted on this thread. Any questions on the technical side are welcomed as well, either about the new version or the current version.

what if I swipe the domain name?>:D no thatd be a dick move xD But anyways, thanks for the port to windows. NOW I HAVE TO GO, FOOD AWAITS. Good luck with the branch. I think at one point everything should just be merged together and be called just ‘cataclysm’ again. OR WHATEVER;-; IM RAMBLING

EDIT: You should probably put this in the contributions/mods section, itd be more fitting then…bugs and technical help

This wouldn’t be for my own branch, nor is it really a mod. It’s just a core part of the game.

A major reason SDL seemed so much faster, is that rather than a 25ms timer on movement, it was a 1ms, so essentially it ran 25 times faster. I've changed this in the new catacurse so it will act faster as well. What people are calling performance, isn't actually performance for the most part, it's just sleep timers. But for real, actual performance, the old version uses GDI, or Graphics Device Interface, which a in-built windows library for handling graphics. So it looks and acts like a console, but is actually a 2D graphics engine that pretends to be one, which isn't ideal.

I actually have a single question.
You mentioned GDI being the core of the problem for the build that, as you claim, emulates the console. It means that your feature, the catacurses stuff that you talk of, essentially push everything via the handler, be it GDL or the game-wide popular SDL. You mention a timer that was set to ‘25’ instead of ‘01’ on the end that you designed. So what I’m reading is that, if I understood you well, GDL failed to be fast, SDL was introduced and solved the problem, and the setting was all the same for all builds.
Just so you can get more familiar with some of the issues we’re encountering while playing, the actual slowdown is relative, which means that, other than the fact everyone’s been experiencing it, there is an actual “moment” a “crack in the sphere” or if you watch it from some hardware monitor app, a “spike” showing us there is code to be cleaned.
The real deal here is, if introducing SDL was the key to obstruct such occurences, and to get the game to do other things - such as smooth effects, sound and even tiles for nicer animations, wasn’t the catacurses in principle the offset gear? I could agree GDL is obsolete for, say, textured viewing of a generated map, because it’s greatest flaw lies in the fact that it cannot do any of the fancy stuff DDraw is all about. I remember Diablo 1 had exactly the issue we’re talking about, so eventually they upped the looks with consumers market’s (commercial) DirectX. I also remember the postulate about game programming and it tells us that 25 is the default for real-time routine responses, and the 1 ms setting was the one for everything else.
I am, however, very eager to see how a vast, detailed world such as this behaves through native console emulation in XP, which is loading a kernel extension in a nutshell, only with some privileges over the main line of the kernel code windows is constantly running. I’m just glad you like the challenge.

Well, catacurses is essentially two parts, a logic part, and a display part. Neither one was very optimized before. SDL helped to alleviate some of the issues, however SDL caps out my processor on a machine I have that has no video card. Optimizing the logic, which I have done, will help BOTH sides, as they share a code base for inserting stuff into the screen buffer. Once it’s in the catacurse buffer, you can use SDL, the console window, or someone can be free to write an OpenGL or DirectX front-end. Using the low level console, though, improves the display performance much more than SDL could ever do, but at the same time kills tileset support for it (unless someone made an actual font file with glpyhs for items, then the console could use it). GDI is known for bad memory usage, so it was likely leaking some memory somewhere that had to be cleaned up, causing said spikes. But much of the sluggish feeling, was indeed from the timer being different. To this day, as far as i can tell, the normal curses build uses 25, and SDL uses 1. I’ve began playing again, and even I notice a difference in them, which is why I went ahead and changed mine to 1.

In short, regardless of if SDL or a console window is used, it will perform better, and there are also a few bug fixes in the behind-the-scenes code as well.

I’ve tried messing with SDL outputs. What I know is that it represents a tool for:
a) helping less skilled individuals to program content and interact with it through native hardware API
b) helping bigger projects keep up with industry standard multimedia entertainment through a wide database of functions that are proven to deliver some quality.
In this sole case, Cataclysm_tiles lets both driver and services in Windows use the resources in a way, to crudely describe it as - “Hey, let’s just open a window here and let this software manage its own needs” - and nothing more. The way I imagine it, the same case would be to open the doors of a small apartment to a classical music orchestra, and let them place the big concert piano anywhere they like it, nevermind the walls. I never ever said, that is on this board so far, that creating a fun piece of software that is easy to work with is an easy task. The GDI part was proven guilty for more than one disasterous roguelike, but those projects were programed in Unix and only ported to win32, to my knowledge. On the other part, many other successful projects that were designed for win16 and win32 used only the draw_ bit with a couple of more to have a ‘windowed’ mode to serve as help with the native color, resolution and refresh modes that a video card will provide once it actually takes over memory and display resources. That’s why I am thrilled about the curses for Windows, because if I can make my shell to tell the graphics card to draw 120 instead of 80 characters per line and provide a font to that part, it’ll mean console speeds as seen in modern Linux systems.
At the moment, or so you know, _tiles build is as savage in terms of overall playability as the final GDL port build, prior to introducing SDL (0.4). However, the native 12 times 12 for Windows users is still fiendishly fast even on a very, very low-end computer.
What would happen if we used sprites to draw things from down the low-level? Just curious.

Anything you can do with SDL, you can go with GDI, but SDL will be better performing.

On an unrelated not, I took a comparison screenshot of versions with default settings. The top is the newer build.

I expect tiles will be somewhat slower with a similar level of optimisation, but probably not by very much.

It will not only be blitting graphics instead of rendering fonts, but it will also be doing alpha blending between different levels of tiles, where with text rendering it picks a highest-priority charater and displays that. Also if we do any tile rotation, that’s a fairly expensive operation.

Well If i have time, I hope to ressurect either my OpenGL version or my DirectX version, which would make all of that trivial on most machines. OpenGL is cross-platform, but also a good deal harder, as being a Windows programmer, I’m so used to using DirectX.

Yes Kevin, but if you used sprites and images, and not just call the SDL graphic extension to beautify tiles, you’d get much, much more with a cleaner look.
I’m only concerned for the well to the whole “feel” of the game, to steer the entire buildup away from the flashy, intsta-fun of a console arcade shootout game.
I could look up some very interesting articles on programmers’ view of their code, I could think of a few after I’m done translating the game.