411 replies to this topic

[Master Maniac]

I suggest a "Test Mode" for scripters. So that we can run scripts in the editor and make sure they work properly without having to open the player.

[Mitchfork]

No No NO! My biggest peeve with any DIY game creation system is THE LACK of a color-set system. Why should I have to make several color-swapped copies of a graphic when the system can do it for me?

Give us the option to have one or the other, and define our own palette sizes and the like, how many color sets, and the like. I'd rather go through the tedius process of setting up a the palette system manually than make hundreds of copies of the same graphic with color swaps.

Hundreds seems like a bit of hyperbole. Considering you can take a "tileset" (in the purest sense, just an image with all the tiles you use in an area) and change its palette within a few minutes in almost any decent image editing program, I don't see the huge problem.

Consider it this way; if the choice is between complete color freedom (at the cost of convenience) or a potentially overly restrictive system (ZC), I'll give up convenience. ZC is particulary bad about this because it only gives you 64 colors per palette (CSets 2, 3, 4, and 9). Unless you give up some of those colors all of your sprites have to use the same palettes globally. Considering that "graphically intense" games like Minish Cap are brutal on color space, this makes using those graphics (without loss) an exercise in frustration.

I see where you're coming from, and I see it being a problem for some applications, but not enough for me to support keeping a palette system as the only option. But who knows, I'm not developing this and its possible that support will be there. As long as it doesn't fully replace a palette-less system I'm totally fine with it.

[Saffith]

I would prefer an expanded version of the current system. Something like CSets of at least 16 colors, no limit on CSets per palette, and optional 32-bit color on a per-tile basis (like 2.50's 8-bit tiles). There's no sense in needlessly removing existing functionality.

[Zenith]

That's literally exactly what I was going to suggest: the ability to add additional CSets onto a pallette. Maybe also the ability to add additional sprite CSets?

[aaa2]

I thought that the colorshift they wanted to implent sounded like a 32bit color version of palette swapping. But i just had a new idea. Why not allow for a set number of "shift-sets" what i mean by that is that you have given the whole spectra of colors. Then in this spectrum of colors you can choose certain divisions like red to orange and another division blue to green. For each of those color divisions you then you set a colorshift. This shift-table then is saved as something that works in a way similar to a c-set. Once all shift tables are saved they should be able to be used in a similar manner like c-sets do. Also another idea i have is to allow changes in brightness to add more control. The 32-bit analogon to c-sets as well as the brightness information should then be saved on the screen together with the graphic

[Cukeman]

On the topic of CSets, I was wondering why we have so many constant CSets, and so few Level CSets.
I don't see why they couldn't all be level dependent, since it would be easy enough to copy a CSet to
another level if you didn't want it to change.

Edited by Cukeman, 04 August 2011 - 08:56 PM.

[Alestance]

I see where you're coming from, and I see it being a problem for some applications, but not enough for me to support keeping a palette system as the only option. But who knows, I'm not developing this and its possible that support will be there. As long as it doesn't fully replace a palette-less system I'm totally fine with it.

I wouldn't want it to be the only option, don't get me wrong, but not having a palette system, even if it takes a while to set up on your own, would make or break my usage thereof.

Like I said, define how many colors in a color-set, and how many color sets you can use on your own. Zelda Classic is practically the only game development application that even uses palettes anymore, and I like limiting myself to a set amount of colors.

[Gleeok]

This is always the popular topic. There are a few things I do have some problems with.

Palettes: Whether many of you are aware of this or not you're basically suggesting a rendering and palette library that is exactly identical to the functionality of allegro. One of the main reasons to even think about a re-write/zc2/Game-Maker 2012 or whatever you want to call it would be to finally be rid of the ancient zc curse that is allegro. IIRC it's going on 15 years old now, and in computer years that's old. Take a look at allegro's predecessor "allegro5", which doesn't even support palettes. In fact, no up-to-date library supports them anymore, and there's reasons for this. To be honest the very idea of using software rendering by default is just sickening to me. Think about it, ZC can barely manage decent framerates at a 320x240 (ie; 256x224 or whatever the actual nes dimensions are), what's going to happen when you increase this quadratically? The solution (I think) to this is simple -- simply require a suitable graphics card that's no more than 8 (or 10 by the time you can play it) years old. Then that opens up the option of using fully hardware accelerated Fragment Shaders to render paletted textures. Texture look-up I've read is fairly fast. And heck, why would you not want to have the option of directly using programmable shaders? Of course in this case these requirements should only apply to palettes I'd imagine.


Also on a different note: There is a very nagging feeling I get just thinking about working on something that so blatantly violates DMCA and infringes on others' IP. What if the project is a success? What happens when it gets ports to the wii or the PS3/PSP/iPhone or whatever? It's no longer a question of if people get served or cease and desist comes, but when it will. ZC stays under the radar because it doesn't even exist in the same universe as Nintendo. In fact the only thing ZC is really competing with ATM is an NES LOZ ROM. It's all speculation but it does bother me, and to be brutally honest I'd rather work on something that isn't blatantly illegal, or to put it another way, have little interest in even putting a decent amount of effort into something of the sort. Of course, something that can recreate ALTTP (but doesn't directly) is another thing to think about.


Another overlooked idea is having the project open source. I'd think that having this open-sourced would lead to far more benefits than negatives (if any negatives at all really). And if something starts to get developed I'd like the mentality to be "Why make it closed source", as apposed to "Why open source it".

[Cukeman]

Now that you mention resolution, it would be great if we could use/see the 8 pixels that get cut off along
the bottom of the screen. It's a bother designing around that just to recreate playing NES Zelda. It should
at least be optional.

[aaa2]

@Gleeok's DMCA concerns

I think we reached a point where the internet as the www soon won't be secure anymore for something like zelda classic or anything creative in such a way. Copyright in any kind of manner cripples people's imagination. I hope one day somebody decides on a www-like system for newsgroups like you put a certain type of header that acts as a trigger to the newsreader and then add html code that the newsreader redirects to a webbrowser so that conversations can continue anonymously but still as comfortable as they do on the internet. The internet is a far too controlled entity that doesnt even allow for things like conversations about suicide. Thats why a new anonymous entity has to be found. Since newsgroups and the usenet in general can't be censored and offer the right infrastructure they should be used to build up a structure that is similar to the internet but without censorship and anonymous. Web adresses would of course then then be replaced by a tree adress like sci.physics.foundations an adress for a zelda classic or zelda modern discussion could be alt.games.zelda.fangame.classic.modern or something similar

[Master Maniac]

Why not use the CSet system, but have unlimited CSets per palette? Or at least a higher number like maybe 20-30 CSets. Or at least have the palette system and have all graphics in 8-bit? Personally, I'd never be able to manage having to select every single color from the visible human spectrum as I use them.

All I want is a color select system where you can save the colors you want to keep to a few libraries of colors that's already been selected. Similar to the way MS Paint works with their colors, except with a bigger palette library. That way we can save as many colors as we want into a color template without having to manually select them every single time.

[Gleeok]

You're not understanding me. >_> What I am saying is expose palettes as fully programmable, as in: You can write your own however you want, or use the default 1024 different palettes of 256 colors each code, OR, if you hate palettes like I do then don't use them at all.. I realize most of you are not programmers, so to put it in layman's terms: You can send a script directly to the graphics card and have it ouput any color you want.

I have not tested these (since I don't use palettes ) but I reckon there'd be a few ways to do this:

CODE

//the slow way
uniform sampler2D texture;
uniform vec3 palette[256];

void main()
{
    vec4 color = texture2D(texture , gl_TexCoord[0].st);

    gl_FragColor = vec4(palette[ get_the_index ], masked_index ? 0.0 : 1.0);
};

CODE

//and the fast way
uniform sampler2D palette_texture;
uniform sampler2D texture;
uniform float current_palette;

void main()
{
    vec4 color = texture2D(texture, gl_TexCoord[0].st);

    Vec2 index = Vec2(color.r, current_palette)
    vec4 texel = texture2D(palette_texture, index);

    gl_FragColor = texel;
}

Obviously this would be preferable over allegro, no?

[Cjc]

This is always the popular topic. There are a few things I do have some problems with.

[Excised]

Also on a different note: There is a very nagging feeling I get just thinking about working on something that so blatantly violates DMCA and infringes on others' IP. What if the project is a success? What happens when it gets ports to the wii or the PS3/PSP/iPhone or whatever? It's no longer a question of if people get served or cease and desist comes, but when it will. ZC stays under the radar because it doesn't even exist in the same universe as Nintendo. In fact the only thing ZC is really competing with ATM is an NES LOZ ROM. It's all speculation but it does bother me, and to be brutally honest I'd rather work on something that isn't blatantly illegal, or to put it another way, have little interest in even putting a decent amount of effort into something of the sort. Of course, something that can recreate ALTTP (but doesn't directly) is another thing to think about.
Another overlooked idea is having the project open source. I'd think that having this open-sourced would lead to far more benefits than negatives (if any negatives at all really). And if something starts to get developed I'd like the mentality to be "Why make it closed source", as apposed to "Why open source it".

Zelda Classic is a great program. But it has its quirks and redneck fixes for everything. Multiple rewrites have been suggested, but I think we need to go in a SLIGHTLY different direction if we DO rewrite.

Scripting needs to be in from the beginning. I want to abstract away from hard-coding everything, opening room for more complex bugs and messy coding that hasn't been touched since Phantom Menace managed ZC. In addition, it would be extremely helpful to pull away from the legacy ZASM and ZScript using Python.
The only things that should be hard coded are cameras, collision and the scripting interfaces. Enemy AI, items, combo types, etc.. should all be driven by scripts for increased modularity and simpler engine upkeep. (most things will be pre-scripted so it will still be completely possible to make a game without scripting yourself)
This would also nearly eliminate the need for quest rules and screen data.

Drop Allegro in favor of SDL. This will increase portability and expand it to, say, the Wii.
Use wx for a GUI. That way you get a NATIVE interface.
Support full 32 bit color. (You'll still be able to use palette graphics if you want them.)

Simplify the interfaces that n00bs usually ask about. Simplify shops. Make messages easier to use. Make it completely obvious how to do everything. (But don't bring in the ribbon, or I will kill somebody. I hate that thing.)

Remove the arbitrary limits. Why only 32 ffcs? Use dynamic allocation, people!
What's 1 byte compared to 100 megs? Almost nothing. Bring internal values up to 4 byte sizes.
Extend access of global game variables and all counters to the subscreen.
The limits ZC has are just ridiculous. Game engines should be limited to your CPU and imagination.

[Excised]

What Beefster has envisioned is hardly an infringement on anyone's intellectual property. If anything, he's taking the concept of Zelda Classic and converting it to a skeletal engine that exists simply for the sake of creating games. It extracts all the intellectual property. If collision, camera framing, and scripting platforms are the only things hard-coded into the program, there is no conflict of copyright.

The creators of this new program (which I would call "Quest Modern", a title that is sufficiently generic) cannot be held responsible for scripts that fans write and incorporate into the program (IE scripts that make "Quest Modern" simulate a Zelda game). Since all non-basic engine mechanics are handled by scripts and not the engine itself, the only infringement that occurs is that made by an individual user (not the developers of the program). Therefore, since there is no Zelda content hard-coded into the program, there are no grounds for litigation.

In essence, the program becomes a platform through which users may create two-dimensional games and share them with other users, without the muck of designing and compiling an executable file to run it.


I really like the idea.

[boltfox20]

Is this still being worked on? I'd love to know the progress of it.

[ShadowPC]

I dont want to learn scripting. But it would be nice with a rewrite.