[2.60] or [2.50.x] Write to More Attributes and Vars; more tile pages, more DMAPS, etc.

Suggestion: Add the ability to write to all the enemy/item editor variables, and attributes; and to the link vars, and attributes, such as Link->Tile. This would go a long way to making multiple player-characters viable.

A far larger number of available tile pages (for 8-bit graphics quests), custom palette definitions (rather than CSets), and a huge max DMAP/MAP count would be nice for 2.60.

By custom palette definitions, I mean being able to manually take swatches from a palette, and arrange them in any desired order, to make a 'custom CSet'. That would allow more diversity, for 8-bit graphic design. Otherwise, tile page caps constrain you out of options rather quickly.

I support this, most GUI editors allow you the choice of either coding, get your own stuff, or grabbing shit that's already there and have the code done for you. This is 2015 not 1986.

I'd think that the color palette of ZC would have to support at least 32-bit for this
(I played around with ag.cfg, and stuff looks glitchy but I changed it back)

Edit: Not sure if it's completed yet, but Allegro5 seems to be more modern it's still limited but it's good for what we need if the devs don't feel like using another framework.

TBH, 32-bit would be wasteful, given that no human being can differentiate between 24-biut and 32-bit colours.

IWhat I'd like to see, are options for user-defined CSets, and CSet behaviour. Just make an 8-bit CSet from a 24-bit Palette, and apply it as needed. That would also end the problem of bank-switching CSets out of the main palette. In general, my wish is that sprites/tiles/combos don;t change colour, unless I tell them to change colour. Get rid of level-based CSets, and make the Cset palette combo-specific, selected in the combo editor; with easy -/+ rotation between all user-defined CSets.

Quote:

---

Originally Posted by Samer

Edit: Not sure if it's completed yet, but Allegro5 seems to be more modern it's still limited but it's good for what we need if the devs don't feel like using another framework.

---

It's not about what the Devs would like or dislike. I guarantee you there isn't one that likes Allegro 4. The work or moving to another framework is just too much.

Quote:

---

Originally Posted by ZoriaRPG

TBH, 32-bit would be wasteful, given that no human being can differentiate between 24-biut and 32-bit colours.

IWhat I'd like to see, are options for user-defined CSets, and CSet behaviour. Just make an 8-bit CSet from a 24-bit Palette, and apply it as needed. That would also end the problem of bank-switching CSets out of the main palette. In general, my wish is that sprites/tiles/combos don;t change colour, unless I tell them to change colour. Get rid of level-based CSets, and make the Cset palette combo-specific, selected in the combo editor; with easy -/+ rotation between all user-defined CSets.

---

8 bit palettes are more than enough for ZC. It'd be best to have it so anything can have it's own full palette(256 colors) and you can have as many of them as you want. None of this CSet swapping into one palette nonsense.

Has anyone ever hit the tile, map or dmap limit? Yes, it is possible but is it likely? I am trying to think how one would run out of tile space, even with all 8 bit tiles, unless you are making a very very large quest.

In any case none of this is likely feasible for ZC as it is now. You cannot write to certain values because doing so would interfere and possibly break internal workings.

Quote:

---

Originally Posted by SUCCESSOR

8 bit palettes are more than enough for ZC. It'd be best to have it so anything can have it's own full palette(256 colors) and you can have as many of them as you want. None of this CSet swapping into one palette nonsense.

---

That's what I said. The main thing, is to ensure that each of those palettes is not intrinsically linked to the colour swatches of the others; hence, each may be unique, and thus, each is drawn from the same 24-bit source as the present palette generation.

Quote:

---

Has anyone ever hit the tile, map or dmap limit? Yes, it is possible but is it likely? I am trying to think how one would run out of tile space, even with all 8 bit tiles, unless you are making a very very large quest.

---

Sadly, yes, almost, and no. I've run out of tiles making everything 8-bit; I've run out of maps by using every layer possible: Each primary DMAP uses seven maps. Thus, the map cap of 256, makes the effective maximum DMAP cap superfluous: It grants 37 maximum DMAPS with full layers and 8-bit graphics... It pretty much made the entire concept of a project that I had designed, impossible; so I scaled it down severely.

Quote:

---

In any case none of this is likely feasible for ZC as it is now. You cannot write to certain values because doing so would interfere and possibly break internal workings.

---

Possibly, probably, who knows. It's something to keep in mind for the future. I don;t expect any suggestion to suddenly materialise, but sometimes, they do.

a slide bar tile interface would be nice. It would also be nice if 'tile to combo' x-fers had an ability to 'apply to all' option when it was pertinent. It would also be nice if combos could be a bit more organized in a way that x belongs in combo folder x, b belongs in b, and that each folder could be called up into the current working interface as needed.

Might be too much to ask.

J~

Quote:

---

Originally Posted by Jaydeadone

a slide bar tile interface would be nice. It would also be nice if 'tile to combo' x-fers had an ability to 'apply to all' option when it was pertinent. It would also be nice if combos could be a bit more organized in a way that x belongs in combo folder x, b belongs in b, and that each folder could be called up into the current working interface as needed.

Might be too much to ask.
J~

---

That's how Solarus handles it, so it's not beyond reason; but not an easy objective for 2.60 most likely.

I rather like the way that Solarus handles tile panes, and sprites. I hope that Christopho managed to add the 'add PNG' menu that I suggested in the next update, as the only downside, is that adding files requires numbering or naming them, and then manually moving them into the correct paths; and ensuring that you name the game object to match.

Still, larger combos, and better combo page handline would be nice. It really depends on how much 2.60 shifts the engine machanics, as if they can do custom CSets as described above, they'll need to account for that in the engine, so this type of thing may be possible.

I'd also like to request this: Full-screen size screens. Get rid of the empty space, as a quest option, and allow an overlay passive subscreen, with the same dimensions as the game screen.

Part of the problem with these '2.6' threads is always that half the suggestions are (variable difficulty) reasonable within what zc does, while the other half are pretty much impossible without creating a new/rewriting the code base entirely. Consequently, the exact same, yet inverse, thing happens in threads about 'zc 3.0 from scratch', in which half the suggesting are based around current zc functionality. ...I don't really have a point here, I just find the irony highly amusing. :)


Solarus is pretty cool. Too bad it's not GPU accelerated.

Quote:

---

Originally Posted by ZoriaRPG

I'd also like to request this: Full-screen size screens. Get rid of the empty space, as a quest option, and allow an overlay passive subscreen, with the same dimensions as the game screen.

---

So essentially framing the game in the sub screen? That would be kind of cool. Maybe with the ability to change how it looks per d-map, controlled in either init. data or screen data. That way you could keep a constant name or 'mood' of the area you are currently playing in. I like that idea. Simple, but powerful.
J~

Quote:

---

Originally Posted by Jaydeadone

So essentially framing the game in the sub screen? That would be kind of cool. Maybe with the ability to change how it looks per d-map, controlled in either init. data or screen data. That way you could keep a constant name or 'mood' of the area you are currently playing in. I like that idea. Simple, but powerful.
J~

---

I was thinking about most JRPGs, where the menu opens over the game area, only when called, and later Zelda games (e.g. Z3), where the passive subscreen is a full-screen, transparent overlay