TomenetGame / tomenet

TomeNET is an online multiplayer roguelike role-playing game
https://www.tomenet.eu/
Other
69 stars 11 forks source link

Windows graphic tiles #27

Closed jezek closed 2 years ago

jezek commented 2 years ago

Changes mainly to ./src/client/main-win.c to make usage of graphics tiles work in Windows client. All other files contains mostly cosmetic, comments or doc changes.

Can be tested with https://github.com/jezek/tomenet-graphic-tiles

jezek commented 2 years ago

I've managed to make graphics tiles work with Windows client. But before merging I have some questions and depending on the answer there could be some more things to do.

  1. Should I squash similar commits to make fewer commits for this PR?
  2. There was some previous attemp to make graphic tiles work, I cleared all the code and resources (some bitmaps). Is it ok?
  3. Currently the loaded graphic tiles bitmap, set in configuration files, is resized according to window font size. The problem could be when some 2 windows that are using the graphic tiles have very different tile dimensions. Eg. when one widow has tile dimensions 8x8 and another 20x20. When you use bitmap with 20x20, then the resized 8x8 tiles could be ugly and vice versa. The idea to "fix" this could be, to specify more tiles in config (separated by some character, eg. "graphic_tiles = 8x8;9x15;20x20) which share the same mappings (the mapping file name is created from first value, here it is "graphics-8x8.prf"). And then the resizing to concrete window size will be from the bitmap with most similar dimensions. Is this a good idea worth implementing?
  4. The resized tiles (and masks) for each window have their own in-memory bitmaps. But windows with the same tile size (font size) could share the tile and masks bitmaps. This would save some memory. Is this needed in this age when memory is not a problem for most people?
  5. Also some windows like item, chat, ... are not drawing graphical tiles ever (for now) and don't have to have created memory bitmaps for them. Maybe we could switch usage of tiles on/of per window to save some memory again. If a graphic tile should be drawn in a window with graphics tiles turned off, some predefined (not used) character or tile could be drawn, so user would see it and can turn the graphics n for the window. Is this a good idea?
  6. When server sends character data, it needs to send 4 bytes for character instead of 1 byte, before USE_GRAPHICS. Those 4 bytes are sent even when no graphics is used in client. But the server and client know both the max character value and therefore send only needed number of bytes per character. When there are no re-mappings, or only graphical font is used (the max value is 255), only 1 byte for character will be sent, when the max value is less then 65536, then 2 bytes will be transferred, and so on. This would help to save some bandwidth on users, which don't use graphical tiles. Shall I make this?
  7. In game menu for changing graphics and tiles and other things related to graphic tiles, like the window or font in-game menu. Do we need such a thing?
  8. There is a code in the wwindows client, that makes some kind of menu, where user can switch graphics on/off (this menu is not in x11 client), but I can't find a way to trigger or show the menu. I can't test the code I possibly make for the turn on/off graphics feature. Is the code alive? How can I make the menu appear?

Thank you for your time.

mhirki commented 2 years ago

Nice work. Here are some answers.

  1. I guess it may be useful to squash a few commits.
  2. I think the previous graphics code doesn't matter.
  3. This is probably not worth it. Resizing should be fine.
  4. Yes, people have plenty of memory these days.
  5. It's probably safest to have graphics on for all windows because the content for each window can be changed live through window flags.
  6. This sounds useful. If someone wants to play with ASCII graphics, then it makes sense to only send 1 byte for every character on the screen.
  7. I guess it would be nice to change the tileset on the fly. Loading a new tileset on the fly is probably takes some effort so it's not a high priority.
  8. You need to compile a resource file that has a menu definition. Have a look at angband.rc. You just need to replace ANGBAND with TOMENET and you should have a working menu definition. Then just compile it with windres and link with the rest. And also enable MNU_USE in main-win.c.
jezek commented 2 years ago

@mhirki Thanks for answer.

I'll continue work on the numbers 1, 6 and 8 from my questions. Number 7 can be done later.

CBlueGH commented 2 years ago

Nice job! So /lib/xtra/graf is now /lib/xtra/graphics, the BMP files are deprecated, and you have an example graphical font we can add to that folder for now?

jezek commented 2 years ago

Yes, I've made some tiles and mappings. It contains bitmaps for all floor characters I could test. I'll add it into next PR I have to make, cause I found an error I introduced to server when converted all the char to char32_t in previous commits. I forgot to rewrite the unmappings ([rf]_char_mod) from an array[255] to dictionary (as in client). I have the fix ready, just need it to test.

CBlueGH commented 2 years ago

Btw, I recompiled the client and I get a packet error when trying to login to existing (not updated) servers. It seems some protocol backward compatibility is missing or not working correctly. Or maybe that is the error you spoke of. (Edit: with both, Linux and Windows client. In Windows client this will result in nulled/garbled stats and everything typical.)

Edit 2: Oh, it's probably just because of the protocol changes that assume 4.8.1 for both, server and client, without bumping the version to something like 4.8.1.0.0.1, so I'll just update the servers and that's that. No problem, we can keep 4.8.1.0.0.0, no need to bump it since this is a non-official version anyway.

So, the new code is now live on our servers actually!

jezek commented 2 years ago

@CBlueGH

So, the new code is now live on our servers actually!

So let's hope, nobody maps a character to some big number, or the server crashes... the fix is in #28

So the crashes you experienced should not occure because of the mapping. Was it the versioning?