User Tag List

Results 1 to 10 of 14

Thread: Planned Features, Limitations

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #4
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,826
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,961
    Level
    33
    vBActivity - Bars
    Lv. Percent
    26.44%
    Quote Originally Posted by CJC View Post
    I don't mean to be an idiot, but could you please elaborate on what you mean by 'same texture'? I don't understand what the grain of the image has to do with anything.
    Sure, sorry.
    Imagine the tiles in zc as a tilesheet, image, or texture (they all mean the same thing pretty much) on your hard drive as a .png file. A tileset is just an arrangement of rectangles and other data from a base image. The tileset itself does not contain pixels or other image data, it just has a pointer to a texture in memory so we know what to draw.


    For example, this is a "texture", a tile would be a single rectangle of this texture expressing an x,y,width,height with animation and other data, and a tileset is a collection of tiles in an array. At least this is how I do it. I don't know what other people do if they handle it differently (Actually, I have seen some bad implementations of tiles before, but I'm not counting the bad ones).

    The main reason why I won't allow multiple images per tileset is because of performance (also because it is much easier to code). You could say this intentionally forces good mapping practices so people with no idea how graphics cards work won't shoot themselves in the foot. In other words, if you draw a map layer using a single tileset the following is guaranteed to happen by the engine:
    1) The rectangular tile region of the screen that needs to be drawn is pushed into a tight array designed for one purpose - to prepare to send directly to the graphics card.
    2) When the rendering happens, it sees that no OpenGL state needs to be changed for a very large length of the array, so data does not have to be flushed often, if at all, and the result is the entire contents are sent to the GPU in a single call. Not only is this fast, but it is shit balls fast.

    Hope that explains everything.


    Quote Originally Posted by bigjoe View Post
    Will Jobs and Character Classes be ,for all intents and purposes, synonymous? Meaning, if you wanted to have Jobs be changeable at will like in FF3 or FF5, will it be done by having the menu alter the Character Class setting?

    EDIT: I guess what I mean to ask is will you be able to alter Character Class via the menu?
    Hmm.. I think separate lists for those would be a waste since they do the same exact thing pretty much...though if I missed something then tell me.
    Classes are Jobs I suppose...but you'd have to manage it so you can interchange them at will. It's not quite as easy as saying in a script "this.class = white_mage;" but it definately should be doable. ...I just haven't thought about it.

    (remind me later when I start the battle engine).
    Last edited by Gleeok; 12-21-2012 at 04:42 AM.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

Thread Information

Users Browsing this Thread

There are currently 2 users browsing this thread. (0 members and 2 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
About us
Armageddon Games is a game development group founded in 1997. We are extremely passionate about our work and our inspirations are mostly drawn from games of the 8-bit and 16-bit era.
Social