411 replies to this topic

[Snarwin]

Sorry, I guess I was a little unclear; the point I was trying to make is that "editor scripts" would have to be handled entirely separately from "game scripts"--to the point where, in theory, we could even have them use different scripting languages from each other, though obviously that'd be a dumb idea. I just decided to use the word "plugin" instead of saying "editor script," because it's less confusing than having to distinguish between two types of "script."


As long as the back-end code that executes the plugins can handle exceptions, having exception handling in the plugins themselves shouldn't be necessary. I could see exception handling being useful for game scripts, though.


Isometric grids? What use would those be, if we're using square tiles? I mean, unless we're going to go and implement mode7-type effects and such.

[Gleeok]

Isometric grids? What use would those be, if we're using square tiles? I mean, unless we're going to go and implement mode7-type effects and such.

Nope. Better. Scripts can do whatever they want with the view matrix. It's there, so you might as well use it right? Clipping regions will be settable also, but I can give no guarantee that this can co-exist peacefully with other code that does not exist yet.

[Koopa]

We are still planning on having a regular tile grid for maps, right?

One idea was having a grid by default (like ZC) but if you hold CTRL, you can place your object anywhere you want in between grid tiles too.

[SpykStorm]

I think that its wonderful that a replacement for ZC is now being worked on. From whats in this topic, this will be far superior to ZC in almost every way.

[Snarwin]

One idea was having a grid by default (like ZC) but if you hold CTRL, you can place your object anywhere you want in between grid tiles too.

That's a perfectly fine user interface, but the grid and the free-standing sprites would still be handled separately behind-the-scenes, no?

[Joe123]

Yeah, they'd have to be.

[Gleeok]

The way it (almost) is now is each layer can optionally be Y, Reverse-Y sorted, or Texture (faster for old cards) sorted from any given vertex. I took out Back-to-Front because it's basically useless if there's already like 20 layers or whatever there is. Obviously a single layer cannot be given multiple sorting algorithms anyway.

I think the tiles have to be grid aligned, but the sprites don't.... or something. Or maybe the combos do. I don't know. I forgot.

[Snarwin]

For those of us who aren't computer graphics whizzes, would you care to explain what those sorting algorithms actually do in practical terms?

And I've been using "tiles" and "combos" pretty much interchangeably here. My impression was that this new program wouldn't really have "combos" as we currently know them--at the very least, I remember there being some discussion about having separate "layers" for solidity and graphics, and the same abstraction could easily be extended to behavior (ie, combo types) as well.

[Gleeok]

Before you render a group of objects you're just specifying the order in which they should be drawn. That's pretty much it. To do certain things on zc you need multiple layers to work with, however if you can control what goes where then you can do Secret of Mana as an example using a single layer.


Also Beefster; isometric games present no problems graphics-wise, but without some form of dedicated iso-editor this will have to rely on scripting. http://www.gandraxa....projection.aspx

[Snarwin]

Personally, I think ZC's pre-defined layers are a lot easier to work with, from a user's perspective, than specifying the draw-order of every object on the screen.

[Gleeok]

I'm saying you can, I didn't say you have to.

Same deal with blending equations. There are tons of ways you can blend each layer into the one beneath it. A quick google search brings up this:
http://www.quake-1.c...cs/blending.jpg

Note that 'Alpha' blending is the one to the left of the bottom-right most tile.


[edit] - Also someone should make an option "Load from bytecode" or "Compile scripts when run" or even a "re-compile" option, so that people can edit scripts while they are testing them.

Edited by Gleeok, 11 August 2010 - 08:01 PM.

[Zephlon]

I like this idea. I have a few suggestions for this:
* Use file associations so that a newbie can play a game by double-clicking the quest file, or edit it by right-clicking the file and choosing, "Edit with Zelda Modern".
* Support multiple monitors. (I can help test this.)
* Keep the color set system from ZC, but allow more csets and 16 auto-selected tints and shades of the currently selected color.
* Use the actual OS cursor. Although, this was probably going to be done anyway.
* With whatever system is used for defining behaviors of combos/tiles, allow combining behavors. Ex.: Water + conveyor belt = river.
* Have items, npcs, and enemy panels.
* Allow panels to be combined using tabs to switch between them.
* Depending upon which one of the appropriate panels were last focused, change the selected tool.
* Allow an item to be dragged and dropped into a fresher chest.

[Beefster]

I like this idea. I have a few suggestions for this:
* Use file associations so that a newbie can play a game by double-clicking the quest file, or edit it by right-clicking the file and choosing, "Edit with Zelda Modern". Shouldn't be too hard, but it would require an actual installation, which would vary between OSes.
* Support multiple monitors. (I can help test this.) How useful would that be in gameplay? Or are you talking about the editor? There's really nothing stopping you from using multiple monitors/workspaces.
* Keep the color set system from ZC, but allow more csets and 16 auto-selected tints and shades of the currently selected color. We're no longer supporting palletes in favor of 32-bit color. However, we may support a more sophisticated color filtering system so you won't have to make 2 tiles to make a recolor.
* Use the actual OS cursor. Although, this was probably going to be done anyway. Yup. We'll be using wxWidgets for the GUI, so it's not a problem.
* With whatever system is used for defining behaviors of combos/tiles, allow combining behavors. Ex.: Water + conveyor belt = river. Scripting will take care of all that. I suppose you could combine combotypes, though it may cause undefined behavior.
* Have items, npcs, and enemy panels. It will be supported out of the box with a set of default plugins
* Allow panels to be combined using tabs to switch between them. Maybe. We haven't fleshed out the GUI yet. We're mainly concentrating on the engine functionality right now.
* Depending upon which one of the appropriate panels were last focused, change the selected tool. Shouldn't be too hard
* Allow an item to be dragged and dropped into a fresher chest. I don't think you'll need this. Treasure chests will be scripted entities. (More sophisticated FFCs, essentially) Don't worry though, they'll be supported out of the box and possibly have some sort of plugin to make them easier to edit.

responses in italics.

Edited by Beefster, 12 August 2010 - 10:42 AM.

[Zephlon]

How useful would that be in gameplay? Or are you talking about the editor? There's really nothing stopping you from using multiple monitors/workspaces.

I meant that if you add features that break multiple monitor support, fix it. Ex.: In winamp, when you drag the window to a secondary monitor and press the full-screen button, it goes full-screen in the primary monitor.

We're no longer supporting palletes in favor of 32-bit color. However, we may support a more sophisticated color filtering system so you won't have to make 2 tiles to make a recolor.

Will this system colorize the entire tile or change one color to another? Ex.: The green on a tree would change to blue, but the trunk would stay brown.
That sounds kind of hard to make.

Treasure chests will be scripted entities. (More sophisticated FFCs, essentially) Don't worry though, they'll be supported out of the box and possibly have some sort of plugin to make them easier to edit.

Ok.

[Beefster]

Will this system colorize the entire tile or change one color to another? Ex.: The green on a tree would change to blue, but the trunk would stay brown.
That sounds kind of hard to make.

Not really. It takes pixels within a specified tolerance of color and would recolor them, hue shift them, or whatever. I think it would apply, load the new stuff into the graphics memory and use that. You'd still be able to have multiple recolors on the screen at once.

But really, this is Gleeok's domain. I'm no expert on OpenGL.