NPPAngband/NPPMoria QT port

[takkaria]

I think I will start by putting all the dungeon information into a class. I am too new to OOP to try anything like you just described. But I think if I make the class correctly, QT will update everything onscreen automatically as changes happen to the dungeon information. I might even be able to have all the game commands just be signals directly from the dungeon class. QT seems to support this.

We will see how it goes. I clearly have a lot to learn, but this is an interesting new challenge.

This is pretty much what modern V does, too. Except obviously, without using C++ classes; it's just object-oriented C.

[Nick]

I think it's fascinating that we essentially have concurrent rewrites of Angband in C, C++ and Python.

[nppangband]

I think I will start by putting all the dungeon information into a class. I am too new to OOP to try anything like you just described. But I think if I make the class correctly, QT will update everything onscreen automatically as changes happen to the dungeon information. I might even be able to have all the game commands just be signals directly from the dungeon class. QT seems to support this.

We will see how it goes. I clearly have a lot to learn, but this is an interesting new challenge.

[Derakon]

Thanks. I did something almost exactly like that.

Soon I am going to go through all the notes on the Pyrel project. Right now the dungeon info is spread out over about 7-8 different variables. It could definitely be improved. I think the dungeon could be done much better with OOP, and well thought out C++ class. You did something like that already for Pyrel, didn't you?

Yes, though it is exceedingly general and thus may get us into performance problems down the road. It's already causing some degree of trouble with saving/loading, though it's hard to say how much of that is down to our dungeon info representation and how much of it is because of the exceedingly general save/load system.

The basic concept is that the map is a collection of Containers, and each Container can hold any number of Things, from which all in-game entities are derived. There's a Container for each cell on the map, as well as Containers for all creatures, all items, each creature's inventory, each wall, etc. Simple functions allow you to perform set operations on Containers, so you can e.g. get all items in the player's inventory that are usable (as a triple-container intersection operation). This makes it easy to winnow down large collections into just the things you need.

[nppangband]

Thanks. I did something almost exactly like that.

Soon I am going to go through all the notes on the Pyrel project. Right now the dungeon info is spread out over about 7-8 different variables. It could definitely be improved. I think the dungeon could be done much better with OOP, and well thought out C++ class. You did something like that already for Pyrel, didn't you?

[Derakon]

This is probably a bit late, but if it helps these are the predefined colors that Pyrel uses:

    "BLACK": [0,0,0],
    "DARK": [0, 0, 0],
    "WHITE": [255, 255, 255],
    "SLATE": [128, 128, 128],
    "ORANGE": [255, 128, 0],
    "RED": [192, 0, 0],
    "GREEN": [0, 128, 64],
    "BLUE": [0, 64, 255],
    "UMBER": [128, 64, 0],
    "L_DARK": [96, 96, 96],
    "L_SLATE": [192, 192, 192],
    "L_PURPLE": [255, 0, 255],
    "YELLOW": [255, 255, 0],
    "L_RED": [255, 64, 64],
    "L_GREEN": [0, 255, 0],
    "L_BLUE": [0, 255, 255],
    "L_UMBER": [192, 128, 64],
    "PURPLE": [144, 0, 144],
    "VIOLET": [144, 32, 255],
    "TEAL": [0, 0, 160, 160],
    "MUD": [0, 108, 108, 48],
    "L_YELLOW": [255, 255, 144],
    "MAGENTA": [255, 0, 160],
    "L_TEAL": [32, 255, 220],
    "L_VIOLET": [184, 168, 255],
    "L_PINK": [255, 128, 128],
    "MUSTARD": [180, 180, 0],
    "BLUE_SLATE": [160, 192, 208],
    "DEEP_L_BLUE": [0, 176, 255]

Direct RGB tuples are also valid, as in your case.

[nppangband]

The updated color system is now working. It now uses 24-bit RGB colors. Gone are the cryptic color letters like U, or b. The ~35 or so pre-set colors are all read out of the edit files with descriptive text (TERM_L_RED, for example). But the game can now work with and process any RGB color. The edit files can contain any <red>:<green>:<blue> (0-255 value) color as well.

[Derakon]

Congrats on the progress. Being able to load a new savefile without having to restart the program is one of those weird things that really marks Angband as being an old game...

[nppangband]

My latest milestone: The QT port is still a shell, but it now reads and loads all of the edit files. C++ and Unicode strings did not like the parsing code in init1.c, and I would up practically re-writing the whole thing. And I was able to make it so a game can be closed and a new savefile opened without having to exit the game. NPP has the added difficulty of two different sets of edit files that require different array sizes. I thought that was going to be one of the more painful parts of the QT port, and it certainly was.

next up:

1) 24 bit color
2) loading and saving a savefile

[buzzkill]

I think my goal will be to write a quick function that reads the tile from tileset page, and then copies it to a 32x32.png file, and saves it with a descriptive name consistent with the naming convention I want to use.....something like 32xbabywhitedragon.png.

Gluesprites just splits them up, right? Does it give the user any control over the names each file is called?

It's pretty bare bones. It names the files incrementally originalfile_split_xxxx.png where xxxx starts at 1000. There's no configuration for naming options.

I suppose you could then write a script that would rename the files based upon the tiles position derived from the split_file_name and cross reference that with the prf. Whew. Or just do that thing you said.

[Nick]

I must have missed some posts upcoming Angband UI changes. What is your plan?

Well, one of my minions (takkaria ) is going to split all the UI stuff out of the game core, so we can have two separate systems (the core and the UI) which talk to each other. It's not technically a change to the UI, but it means that one could write a completely new UI, and the core essentially provides an API for doing that.

[nppangband]

My feeling on this is that the NPP and V approaches are different enough that it's best to keep them apart, then see what the end results are and probably try to use the best bits of both.

Or else I'll revert to type and pinch the lot from Jeff

I must have missed some posts upcoming Angband UI changes. What is your plan?

The switch to QT and C++ is definitely a commitment. I think it will work well but there is no going back. For example, all 'char' variables are being changed to QChar, all strings will be changes to QString, and all msg_print, msg_format, etc will be torn up as well. But it is nice. QT takes care of all buffer overflow issues, so you don't even have to declare length of strings. For example, instead of adding to a string with something like:

mystrcat(mon_desc, "resists fire", sizeof(mon_desc));

is simply:
mon_name.append = (" resists fire");

[nppangband]

I've got a program for that, GlueSprites. There are probably others that would work just as well, also I couldn't find a "clean" webpage or link to the program. It's a stand alone Windows executable. I can post it to my MediaFire page if you would like.

I think my goal will be to write a quick function that reads the tile from tileset page, and then copies it to a 32x32.png file, and saves it with a descriptive name consistent with the naming convention I want to use.....something like 32xbabywhitedragon.png.

Gluesprites just splits them up, right? Does it give the user any control over the names each file is called?

[buzzkill]

Oh, and Buzzkill, I should have mentioned that when I get around to tiles I will probably break up the tileset into hundreds of individual 32x32 files and load them at startup with a pre-set naming convention. That should make it easy to edit tiles and free us of all the mapping difficulties.

I've got a program for that, GlueSprites. There are probably others that would work just as well, also I couldn't find a "clean" webpage or link to the program. It's a stand alone Windows executable. I can post it to my MediaFire page if you would like.

[Nick]

You go Jeff!!! A maintainer that speaks of maintainence. Incredibly rare 'round here. No offence intended to the fledgling, just a babe really, Vanilla maintainer, whom also seem to have some maintainer blood coursing through his veins. This could be the start of a Golden Era.

Actually quite a lot of maintenance has happened over the last few years - I'm just swanning in at the right point to grab all the glory.

You should get together with that Nick McConnell chappie, I hear he's doing something similar ...

My feeling on this is that the NPP and V approaches are different enough that it's best to keep them apart, then see what the end results are and probably try to use the best bits of both.

Or else I'll revert to type and pinch the lot from Jeff