[quote=“utunnels, post:80, topic:197”]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.[/quote]
Even you are not aware what you actually did is what I said it should be done, which is not to refresh the whole screen when updating each of the game’s sub-windows. The fact it works without flipping the screen is because you don’t really have actual double buffer without hardware surface and full screen, so you can update arbitrary areas asynchronously as you do, and in that case SDL_Flip is identical to SDL_UpdateRect(screen, 0,0,0,0).
So you are really calling the same function as before, only this time you specify particular area of a game sub-window being currently refreshed and only transfer its content to video memory, which is exactly how it is supposed to be and as I said it’s saving quite a bit of CPU time, so if you measure the performances you will notice it’s at least 30% faster.
Now, if you get rid of the rubbish in getch() function you will again boost performance for almost as much. It’s not about whether the game runs fast enough for your taste on your computer, it’s about right and wrong. That the correct code comes with performance boost is just a natural bonus, but the real reason why the code you have there from vanilla build should be fixed is because it’s wrong.
Alright, I’ve got the tiles stuff merged into that branch on my Github repo as well. It works, hurray :)! It’s also very janky, but I think that’s known and acknowledged.
The SDL pseudo-curses stuff, on the other hand, seems like it might be acceptable for mainline in its current state. So, I’ve gotten that submitted as a pull request, and we’ll see how it fares during code review.
Maybe you can create another folder to hold the sdl project like that msvc10, so users have a option to build gdi version or sdl version.
I don’t what do you mean by janky.
Maybe item type can have an integer id like monsters so I don’t have to do a string search for every tile. It can be easily done in itype constructors by increasing a global type id value.
For example, according to mapdata.h, “t_null” can be mapped to 0, “t_mutpoppy” is (num_terrain_types-1), “fd_null” is num_terrain_types, “fd_acid_vent” is (num_terrain_types+num_fields-1) and so on.
Creating a separate project file for the SDL version is entirely possible, but also not really my field of expertise. It’d probably be pretty simple, though.
Ugly stuff which may or may not be a hack, in this case.
Which is not necessarily YOUR fault, of course ;). It would, as you say, be really nice if there were a better way to handle associating tiles with entities.
I updated with my previous idea. Now every itype has an unique iid that can be used to map tile. Gfxwindow.cpp now uses a vector instead of map to store tileset infomation so it should be faster on rendering.
There isn’t much to do now I guess. Maybe a pixel artist will be wanted if this goes offical someday, because most of the pictures I’m using to test the code are taken from nethack and dwarf fortress.
What exactly did you change this time around? You’re using a different base version than I am, which makes it hard to see exactly what’s going on. Was it just gfxwindow.cpp and the iid field in itypes.h that changed?
Now, as for using those iids… hmm, it looks like those IDs are being assigned entirely at run-time, which is good. I was worried that you were doing something silly like using implementation details in the tileset data file :P. I’m glad to see that you’re not.
I’d much prefer to avoid the current random-arcane-index method of assigning tiles, though. Rather than giving itypes (etc.) an arbitrary iid field, I think it would be good to let them store a direct reference to the tile they’re using. That would make things a lot more readable and maintainable, I think.
There’s also some more clean-up that would be good before considering this for mainline, but it is nice to have what you’ve currently got as a starting point.
Changes? Yeah, it is based on the version I was using last time. I added iid property and a static counter itype_index in itype.h
[quote=“itype.h”]struct itype
{
static int itype_index;
int iid;
…
itype() {
iid = itype_index++;
…
itype(std::string pid, unsigned char prarity, unsigned int pprice,
std::string pname, std::string pdes,
char psym, nc_color pcolor, material pm1, material pm2, phase_id pphase,
unsigned short pvolume, unsigned short pweight,
signed char pmelee_dam, signed char pmelee_cut, signed char pm_to_hit,
unsigned ptechniques = 0) {
iid = itype_index++;[/quote]
[hr][hr]
I know, but there are many types other than items. It will be a war on many fronts if those unreleated types all use tile references.
I see even monsters have their unique integer id for the reason it will be easier to write AI code, items, on the other hands use string id which make them easier to mod I guess.
If all of them (terrain, field, traps, monsters, items, etc) are defined in json files and open to modders, it will be more reliable to add a tile entry to the json files. For now I just feel it is more practicable if tiles use a more independent module.
Oh, I’m fine with keeping the tileset information in a separate data file, I was referring more to the internals. I’d much prefer doing something like item_ref.type->tile, or terrain_ref.tile, rather than tilemap.find(foo) or the new vector-based approach.
Basically, it seems suboptimal to have constant look-ups in a vector or map. The vector-based approach used a chain of calculations that will probably slow things down, and means we’ve got more magic numbers; and the map-based approach relies on string lookups. And both of them involve a bit of indirection which doesn’t necessarily make sense.
Now, what IS beneficial is the fact that it lets us keep the tiles code a bit more localized, but I think it would be better to have, say, a visual_representation struct that’s set as either a character-fgcolor-bgcolor triplet, or a fgtile-bgtile pair, depending on an “#if (defined TILES)” check.
Yeah, I see.
Almost all renderable(or printable) elements have a sym property, some others are hard-coded for animation or multi-states(like car door).
Maybe that sym can be expanded to a struct like you said (bg, fg, animation, etc).
But I don’t know if I still have the desire to code, as you see, I’m more of a player than a coder so my original purpose was to create a tile window that can help me on gameplay. I really hope you guys can make an official tile feature. I’ll sit back to play I guess, but I’m always glad to help if you need a hand and there’s still something I can do.
Alright, fair enough. You’ve still given us a useful starting point, and I think the ASCII-based SDL version might be merge-worthy, even if the tiles support needs a bit of work still. Thanks for what you’ve done :).
Ah, that makes more sense… I had previously tinkered with that line, because we were having issues with shift events being passed on to getch() (even though getch() is supposed to ignore stuff like shift). But your version is more sensible, AND means that non-ASCII characters should work, if/when we get around to making the code unicode-compatible.
Hmm, if you downloaded the latest file, shift / control should be parsed. My old demo used to have that issue but I fixed it quickly.
I also double checked your github code and yes it is already fixed.
Well, it compiles and links and all on my system, for some reason. Not sure why I didn’t need to explicitly link against Freetype; maybe SDL_ttf takes care of that or something? Or maybe Freetype is standard for native Linux compilation, but not WinGW-based stuff?
However, someone else needed -lfreetype to cross-compile it for Windows. I’ve got a separate branch with a bit more clean-up that’s been submitted as a pull request to the main repository - THAT branch has the -lfreetype bit in there, and all.
How are things coming along? I’ve been keeping track and so far I’ve liked the good news that has come down from relevant folks like utunnels and the rest of the gang on whether tile support is still being worked on. Here’s hoping that the next entry in Cataclysm’s version history will contain some.
Well, the SDL text version got merged into mainline, and I’d like to provide both the classic Windows version and the SDL Windows version when we release 0.6 (so that people can try them out, and we can get feedback on any differences).
We don’t currently have any tiles support that’s suitable for general use, and that’s unlikely to change before 0.6 is ready. I don’t know when we’ll have that, but having SDL support at all certainly helps us along that path.
