Yes, it’s nothing to worry about or plan in advance. Doesn’t make a difference, as once you have tiles you already have the ability to use an image instead of font. It’s easy to switch, or even have them both simultaneously.
As for the key repeating problem, I already solved it, will update the code next time I get a chance.
SDL_EnableKeyRepeat(500, 25);
That’s certainly simpler since SDL_GetKeyState would require separate handling of timing. Be aware however that getch() in catacurse.cpp is already trying to fiddle with timing, most of which seem to unfortunately be just to get a blinking cursors on the map screen and is otherwise unnecessary, if not a source of trouble.
By the way, what I just noticed the other day, is that you don’t really want to put SDL_Flip(screen) in void DrawWindow() function, it’s executed more than once per turn. There is three or four windows on the main game screen, and that function is called at least once for each of them. You only want to flip double buffer when everything is drawn to the back-buffer, not before and not more than once. When I did it properly like that my build gained 40% performance boost. That’s with old catacurse.cpp and MFC, but it applies to SDL just the same. I’ll upload a new release of my mod with those changes in a few days.
Yeah, it’s just refresh call for any and all of the (sub)windows within the game.
What I did is to isolate that swap buffer call, I actually piggy back it within the original function: wrefresh(), so when I call the same function but with “bool really= true”, then it means it should refresh the whole screen (flip screen), while for other times the function will retain its original functionally, like this:
Then I simply placed one of those calls: wrefresh(0, true), at the end of draw() function in game.cpp, two more in explosion() function, for explosion animation and shrapnel animation, also in game.cpp. And one more in ranged.cpp for bullets animation. If you search for “nanosleep()” function you will find those places where you need to additionally refresh the screen beside the one in the main draw() function in game.cpp.
Thanks for working on this utunnels, we really appreciate it.
Just a clarification, we won’t be switching away from curses, we want to keep curses support AND are eager to have tileset support. Ideally it will remain possible to build both with and without SDL support, and possibly make both curses and tile releases.
Can be played over SSH. This is a non-trivial advantage for a significant portion of our userbase. Also, many people prefer to play in their console for a variety of reasons.
Just a quick note: don’t piggyback on the curses functions for non-curses stuff (e.g., don’t introduce another arg to catacurse’s version of wrefresh to control flipping the screen). We’d have to extract that stuff into separate functions, so may as well just put them in separate functions to begin with. Now, what WOULD work is adding a “flip_screen()” function that’s a no-op in non-SDL contexts.
As for why we’d want to keep ncurses: the obvious answer is that it lets the game run in a terminal, which for some users is desirable. And I know we’ve got people running Cataclysm over SSH (one case where SDL doesn’t help us), because one of those users reported a now-fixed performance bug.
So yeah: we want SDL and ncurses, and then everyone’s happy :).
It’s going to be a function call whether you call it foo() or wrefresh(). Why do you think you would need to extract it into separate function or do anything about it at all?
As for why we'd want to keep ncurses: the obvious answer is that it lets the game run in a terminal, which for some users is desirable. And I [i]know[/i] we've got people running Cataclysm over SSH (one case where SDL doesn't help us), because one of those users reported a now-fixed performance bug.
So yeah: we want SDL and ncurses, and then everyone’s happy :).
Who in their right mind would play over SSH and why? Do those people make even 1% of the Cataclysm user base? If networking was indeed important for this game then much faster and better network client could be written specifically optimised for Cataclysm with as little as 20 lines of code, where SDL would help very much by providing fast graphics pipeline. Terminal emulator is just about the worst, most limited and slowest option to put graphics/text on the screen.
Wouldn’t everyone be happier if the game was running faster, smoother, with more colors and more symbols/tiles?
I really don’t feel like rehashing old arguments, especially not in this thread.
Now, as for the SDL implementation: I hacked at it a little, and it works :). I’ve uploaded stuff to the “new-tiles” branch of my Github repository, if anyone else wants to take a look at it. The code is even messier than what utunnels has, but it works. I did make a few changes that will probably break Windows support, though; before merging this into mainline, we’ll want to, well, not do that.
And oh man does that font look weird. It looks like the lowercase letters don’t have a consistent baseline?
We never spoke about this and there is no argument here. I’m simply asking you to explain the reasoning behind your decisions.
So far the only reason to stick with curses put forward is SSH. So I am asking you, who in their right mind would play over SSH and why? Do those people make even 1% of the Cataclysm user base?
Oops, I feel I can’t catch up the discussion after the absence. LOL
Yeah, the font I’m using was downloaded somewhere, I only did a quick google search so maybe it is not the best one I can find.
Here’s how the tiles look like in my current working in progress build. I feel the visible area a bit small because the tile size is 16x16, while the font is 8x16.
As for compatibility, maybe the game can has a dummy window? The dummy window also uses a WINDOW struct, but doesn’t actually show any text, so the general DrawWindow function can be hacked to display it without changing it’s original purpose.
I have some work to do right now, maybe I can try the idea this weekend.
Feel free to hijack DrawWindow all you want. It’s not part of the curses API, so you’re not going to screw up the ncurses builds by changing what that function does. Same goes for all the other CamelCased functions in catacurse, actually - those are all catacurse-specific, so if it would be convenient to have them work differently… as far as I’m aware, that’s perfectly fine.
For the viewport: I’d suggest bumping up the default size, to be honest. The default Windows viewport is tiny. Or better yet, allow resizing during play!
By the way, shouldn’t those windows created by newwin be deleted?
Because I noticed several times you use newwin to create a window in game.cpp, but I didn’t see the code to delete them.
For example, in advanced_inv and look_around.
Yeah, if there are any places with a newwin call and no corresponding delwin, we want to fix those - they’d be memory leaks, afaik.
EDIT: Now that I’ve looked, I see three delwin() calls in game::advanced_inv, but none in game::look_around. I’ll add in a werase and delwin call to the latter function - feel free to alert us to any other cases of missing delwin calls (a Github pull request would be ideal, but a bug report on Github or the forums also works).
So I still edited DrawWindow function to draw the map window instead of adding a new window. I use 24x12 for the display area instead of 12x12 and it looks OK on my PC. I also fixed some key press bugs in previous build.
Changes besides gfxwindow.cpp and catacurse.cpp involved:
game::terrain_view_x
game::terrain_view_y
I use them to record temporary viewport center. Maybe I should edit draw_ter to draw tiles, but those refresh function calls confuse me so I prefer to keep the code a bit clean.
game* thegame;
It is a handle to the global game instance. It is a bit tricky because DrawWindow function will need it, until tile related functions are moved to game.cpp, I guess.
[hr]
How to show tileset isntead of ascii?
While in game, press F3 to switch between ascii map and tileset map.
F5 will reload resouces from disk, so you can edit tileset.json and tile.bmp while playing.
Known bug: press F3 on title screen will crash the game, I need to check if thegame is a valid handle at that time.
Ooh, cool, progress :). It’ll be fun tiles working with the current DDA version.
On my end, I’ve gotten the Linux-ification cleaned up, and the same code should work for both Windows and Linux. Can you grab the version I’ve got up on my Github repo (plus your 3rdparty/ folder, which I didn’t add), and see if it still works for you?
We’ve previously discussed adding a global game* variable, because it does end up getting passed all over the place already. So, if it makes something a lot easier for you, that might be incentive to make that change.
Also, how would you feel about doing the collaboration via Github rather than Dropbox? It’ll make tracking parallel changes (such as the ones that we probably have right now) a lot easier, and we’re more than happy to help you figure out how to use Git and Github if you’d like.
Nah, I just used SDL_UpdateRect instead of SDL_Flip for DrawWindow.
As for performance, I’m not having slowdown issue, except when I was using visual studio’s debug mod (ultra slow).
I changed ttf code a bit though, caching glyph data at the beginning instead of creating a new surface for ever character draw.
