So as for being some one whom has used Zquest almost from the start. I am seeing alot of new things since I last dabbled around probably about `08.
But I have always wanted to smooth edges out and not have the square blocks for sprites and items.
I thought of a way, but don`t know if it can be done in Zquest.
It`s pretty much brakes one single pixel into 8 as mocked up here:
set it up were a new tool or adding a new select option to the color selecting tool.
that allows you to select which region of the pixel.
I also in conjunction with that like to see a true 256 color palette and a seperate section from main and level palettes for system.
So when in full 256 you know that they will still show up right on screen during game play.
Anyt\ thoughts?
https://github.com/A...es/ZeldaClassic
You are welcome to have a look at zq_tiles.cpp, zq_custom.cpp, and tiles.cpp.
I'm not willing to consider stuff like this unless we have more coders on board, or until after we finish the gigantic backlog of features that we are already implementing. This would be a large change, and would require quite a lot of forethought, and planning.
Anything involving collision, solidity, and graphics output needs to be well-wrought.
Think about this: The entire collision/solidity map is a select of four bits at present. If a tile was 64x64 pixels, then a single collision value would be 4096 bits (!!) , and there would need to be distinct checking against a completely different type of overlay. The check goes from 4^4 bits, to 4096^4096 bits for a full collision overlay. (16 cycles, to 16,777,216 cycles.)
There are of course shortcuts to reduce this, but this partly why ffc solidity was such a problem in the past.
I haven't yet managed to get all of the engine collision events to work in the same manner, or via a centralised place. Collision for Link takes place in at least five different ways, using three sets of values/functions under class Link.
Beyond that problem, the largerissues of changing the screen dimensions--these values are hardcoded everywhere throughout ZC, and the map dimensions, would be problematic.
I was considering a way to truncate screen dimensions ( to simulate Gameboy screens ), and in the process, I found that I would need to rewrite bits of the engine almost everywhere. Once a system is in place to set the screen dimensions, and all of the harcoded values are instead, read from a variable, this may be less of an issue.
I added some vars to class ffscript, (in ffscript.h) to do this, but nothing uses them at present. That class is intended to be a new engine core, that I am designing, to make various hardcoded events less hardcoded, and available to any scripting system (sanely). Of course, compatibility requirements will disable portions of it for older quests, which is another issue in making this kind of change.
Likewise, converting to a true 8b palette has serious issues. I would love to offer that as an option, and to load an 8b palette by DMap. Sadly, that is going to be hellish. I do have a quasi-solution that would allow doing that manually by script with SetCSet(int cset, int arr[8]), SetPalette(int arr[256]), SetCSetValue(int cset, int index, int colour). Stuff like that.
Granting this via the editor is potentially much harder, and it would still rely on designing tilesets to use 8-bit palettes. Even so, these are untested, theoretical functions.
You may want to come visit the dev boards on AGN if you want to discuss this in further detail.
Edited by ZoriaRPG, 23 October 2017 - 01:32 PM.