Jump to content

Photo

an idea on tighter resolution in tile editor.

no more block edges

  • Please log in to reply
8 replies to this topic

#1 EnnonFenom

EnnonFenom

    Why, must I clean out Old Lady Simmon's Cave?

  • Banned
  • Real Name:Eric Dethel

Posted 23 October 2017 - 01:05 PM

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:

 

3jM56.png

 

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?



#2 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 23 October 2017 - 01:21 PM

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:

 

3jM56.png

 

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.


#3 Geoffrey

Geoffrey

    Chosen One

  • Members

Posted 23 October 2017 - 02:45 PM

Just use GraphicsGale. The built-in tile editor is a joke.



#4 EnnonFenom

EnnonFenom

    Why, must I clean out Old Lady Simmon's Cave?

  • Banned
  • Real Name:Eric Dethel

Posted 24 October 2017 - 10:33 AM

that`s what I thought ZoriaRPG. i have put a lot of thought into it. And thought of many ways to set it up. But I have only done a small amount of  coding but that was in a c++ tutorial on making a browser.

I never coded anything in Allegro. would love to learn. I got so many idea`s for my quest that is going to require scripts. And btw whom ever is responsible for tall grass next thank you! so much better for unique under combos. Now I would  love to see dry tall grass next aka when burned and just dry grass next for short dry grass to burn. And as for AGN I don`t has access to my old email for that account. I only got back into this account thanks to The Satellite. So I would have to make another account and I kinda don`t want to do that.

 

Geoffrey its not that the built in editor sucks. I actually like the editor just want to see the ability to brake one single pixel to either 2 in each possible direction or into 4 in the 2 different patterns cross or x`ed or into 8 the x and cross overlayed. because it would allow for pointy ears smooth check lines and curves. and would allow for 2, or 4, or 8 colors to fit in one pixel. that would allow for better color gradient for shading and texture of your graphics and if done right a 3d appearance.


Edited by EnnonFenom, 24 October 2017 - 10:35 AM.


#5 Feenicks

Feenicks

    still the harpy guy

  • Members
  • Real Name:Robert
  • Location:dn ǝpᴉs ʇɥƃᴉɹ

Posted 24 October 2017 - 11:21 AM

That sounds like you'd want either vector graphics or a much higher resolution; splitting a pixel into 8 like that doesn't really make sense, anyway [what happens when you're playing on 1x or 2x zoom? What color takes precedence?]

There are other game-making programs that are far better equipped for those sort of graphic requirements than ZC, both now and [I'm going to assume] the future.



#6 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 24 October 2017 - 01:00 PM

That sounds like you'd want either vector graphics or a much higher resolution; splitting a pixel into 8 like that doesn't really make sense, anyway [what happens when you're playing on 1x or 2x zoom? What color takes precedence?]

There are other game-making programs that are far better equipped for those sort of graphic requirements than ZC, both now and [I'm going to assume] the future.

 

Vector graphics? No-one has an XY CRT these days. :D

Do you actually comprehend what vector graphic are, or what the term means?

 

An X/Y monitor has one, or three guns, that draw lines at any vector, rather than one or three guns, that draw each scanline in sequence. (I used to work on those buggers, and the three gun XY CRTs were notorious for failure rates.)

 

One gun XY displays are still used in oscilloscopes. I had previously hacked up an Oscope to a vector arcade board, just to have a portable Asteroids arcade game.

 

He wants higher resolution across-the-board. that is the only way that a 64x64 tile would work, and it would demand a very modern display. Think about these values:

 

Minimum screen resolution with this requested change: 2048 x 1728, not including any Ui elements.


Edited by ZoriaRPG, 24 October 2017 - 01:03 PM.


#7 Feenicks

Feenicks

    still the harpy guy

  • Members
  • Real Name:Robert
  • Location:dn ǝpᴉs ʇɥƃᴉɹ

Posted 24 October 2017 - 02:51 PM

I mean, he's wanting a graphical element, presumably one that would only pop up at zoom scales that demand it, that's defined by 3 or more points on the 32x32 grid he's made [that would presumably want to be a crisp triangle no matter what], which makes for a weird, restricted sort of vector graphic [which, you know, hasn't had a definition restricted to yours for decades]. Vector graphics have the ability to be at an arbitrary scale, so huge resolutions aren't necessarily needed.

I doubt ZC's going to start using vector graphics at any point in the future even more than I doubt it getting a larger resolution, though.



#8 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 24 October 2017 - 08:29 PM

I mean, he's wanting a graphical element, presumably one that would only pop up at zoom scales that demand it, that's defined by 3 or more points on the 32x32 grid he's made [that would presumably want to be a crisp triangle no matter what], which makes for a weird, restricted sort of vector graphic [which, you know, hasn't had a definition restricted to yours for decades]. Vector graphics have the ability to be at an arbitrary scale, so huge resolutions aren't necessarily needed.

I doubt ZC's going to start using vector graphics at any point in the future even more than I doubt it getting a larger resolution, though.

 

No, sorry, try again. Even that definition represents a set of vector in memory, that are rasterised at output; often with various forms of anti-aliasing and artefact correction.

 

Again, the OP is not asking for anything of the sort. he clearly asked for higher resolution output from ZC. With a higher resolution, you can reduce jagged edges, and introduce your own smoothing techniques, but you still have a rasterised image output, however you define it in memory.

 

Without a 24b or a 32b palette, this isn't going to be very helpful in the end, and it isn't like;y to happen in any build of ZC unless someone wants to rewrite maps from scratch.

 

What you are seemingly describing, is vector graphics in memory. That would not even be possible using Allegro 4.


Edited by ZoriaRPG, 24 October 2017 - 08:43 PM.


#9 Feenicks

Feenicks

    still the harpy guy

  • Members
  • Real Name:Robert
  • Location:dn ǝpᴉs ʇɥƃᴉɹ

Posted 25 October 2017 - 10:43 AM

I'm not even sure why this is being argued when both of us agree that whatever's being suggested here is infeasible? It's just pedantry over how one would deal with the triangular elements of a sprite at this point.




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users