101 replies to this topic

[Timelord]

I've previously read the docs on 'converting' anything designed for Allegro 4, to Allegro 5. The process is pretty flipping far from trivial, and guaranteed to break quite a lot.

 

Regarding C++11, I don't even want to think of touching that. I'm far too old to start with YAL paradigm/style. I think in far more...monolithic...terms, than you younger blokes.

 

Above all, I'm with grayswandir. I really don't want to muck with this at present. What I..no, what we wanted, was 2.50.x open source.

 

It's nice to see that there's a future for ZC, but what we wanted to do was improve ZC 2.5, to make more possible within our own scope of priorities. I may as well say here, that some of us are considering a formal petition for the latest 2.5 bases, so that it isn't a complete shock, if we do that.

 

Aye, we want that that badly. We really don't care if we fork it before whatever bugs the core devs want to resolve are fixed. We can always merge things later, or fix things ourselves. This also helps free you to work on zc3.

 

We want to work with a known stable build, and work on ZScritp stuff, ZQ String Contol Codes, GUI things, various flags, and all sorts of other things that would greatly benefit out extremely convoluted projects, and make it possible to do things that we can't do now. We also want to add lexer extensions for other language types. For the3 msot part, this is an intellectual exercise, to do things that we find mentally interesting.

 

Hell, I wanted to try to add ZBASIC (based on C64esque BASIC, because it'd be amusing) and ZCOBOL at one point. There's no good reason for either, but I think--or at least, I once thought that--it'd be fun. grayswandir want sto add Lisp. I also want to add more datatypes, and multi-D arrays, and other things. Im short, we want to evolve ZScript/ZASM for the 2.xx branch.

 

I'm pretty much reaching the point, after waiting, and waiting, that if a ZC2 trunk isn;t available soon, I'm just going to throw it in,a nd move on to something more productive, as I really don't want to wait another couple of years just to start on this. i also know that the core devs have very little ambition to work on ZC 2.x, and that if we don't get it soon, we probably never shall; so ... really I'm pretty tired of the struggle to get started.

 

If you just dump whatever the present files are, we can probably sort it all out on our own. You're welcome to keep doing legit updates, but we pretty much have a solid goal in mind for ZC 2.55+, that is far more lofty than the goals of Gleeok and Saffith, who would never want to expand the main engine using its present components to the degree that we have planned.

 

While AngelScript is neat, it's something we want to address much later. All other concerns aside, I think the combined codebase for three of us, is somewhere over 700,000 lines of ZScript. That's not something we want to port, and we don't need to port it. If AngelScript does make ZC extremely mutable, then a lot of our work will become absolutely pointless, and it's years of work, that we want to complete, and use; not just abandon.

 

If we can modify some features, and expand ZScript, we can do some magic, and put out a solid ZC version in the interim. There's no reason that ZC2 and ZC3 can't evolve in parallel, so that's our goal.

 

P.S. It'll probably be two to three years before this codebase is anywhere near RC phase, so users can forget about submitting quests, or even building quests with it for quite a while. Right now, we don't even have a binary to execute, to see if it'll run, or just crash instantly. I certainly don't want to fiddle with trying to shift around libs, find includes that aren't int he package, or other things like that, in trying to compile it. Until there is a working makefile, or a vc2010 project, it's a moot point.

 

This is exactly why I had such issues trying to do anything meaningful with the 2.50.1 sources: I couldn't test anything that I was trying to do whatsoever.

 

If you want to be hyper-technical, a set of files that a user can compile is supposed to be the main branch, on GitHub, per their policies. All other branches can fail to compile, but the main branch is supposed to be usable as-is; at least how I understand their policies. It'd be nice if Saffith just dumped whatever he uses to build and test this, as he must have...something?

 

Some kind of basic guide on compiling/building for Windows, Linux, and presumably OSX would be flipping awesome. If grayswandir gets it to compile on Linux, we can make a branch for that,a nd from that, I might be able to do an OSX buildset. (My goal would be to compile on both PPC (G5, 64), and Intel. I've no idea what kind of performance hell it'd have on a G5, but it should run. The problem of course, is getting it to work with the older versions of Apple's tools for OSX 10.4.x and 10.5.x. If I can do that, it should work on G5 systems, and Intel systems with 10.4 or 10.5 and later.

 

I don't even run OSX later than 10.6, so, forget testing that. The nice thing about the G5, is that it should be capable of dealing with the performance hit of wasting a core on idle processes for gfx, or whatever the h%ll is going on with that.

 

Anyhow, right now, at present I'm somewhat of a wreck, mentally, and emotionally, so if anything here comes off as overtly angry, I apologise.

Edited by ZoriaRPG, 07 February 2016 - 02:29 PM.

[lonegraywolf]

32-64 issues? I have been involved with a project with those woes before. From experience: Mac OS X development is primarily 64-bit now. Even if the app becomes 32-bit instead, PPC support is basically dead. I will not develop for PPC personally.

Windows and Linux is easier for 32-bit, but I do not know if any new hardware is being made for that.

To Zoria: I am trying to get female set up so that you can use whatever IDE you want. Allegro is the primary issue for me since my windows IDE is VS2015 and it is particular about building all of the dependencies and Allegro 4 was made in a day when Microsoft did not care about standards.

Also: typing this on an iPhone is not ideal.

Edited by Wolfman2000, 07 February 2016 - 02:48 PM.

[Deedee]

While I appreciate the release of this beta source, I do agree that the 2.50.x source would have been much more... well, usable. I know what I want to add to 2.50.x, and I know that these features I want to add are not yet implemented in 2.50.x. However, I do not know anything about ZC 3.0 other than it uses AngelScript, and besides; I want to make an improvement to 2.50.x. That is what I set out to do first. If I can improve on the 2.50.x source, then I will become much more confident in improving on 3.0. Work with what I'm comfortable first, then set out for the unknown.

Not that we aren't grateful for this; we are. It's just that it would be preferable to have the 2.50.x source.

[Timelord]

32-64 issues? I have been involved with a project with those woes before. From experience: Mac OS X development is primarily 64-bit now. Even if the app becomes 32-bit instead, PPC support is basically dead. I will not develop for PPC personally.

Windows and Linux is easier for 32-bit, but I do not know if any new hardware is being made for that.

To Zoria: I am trying to get female set up so that you can use whatever IDE you want. Allegro is the primary issue for me since my windows IDE is VS2015 and it is particular about building all of the dependencies and Allegro 4 was made in a day when Microsoft did not care about standards.

Also: typing this on an iPhone is not ideal.

 

My reason for PPC support is personal. in fact, for years, I waited for 2.50, using my Macs. back then (2005-6), PPC was the only thing around, and there were official ZC builds for PowerPC OSX, but they were all deficient in one way or another; or merely failed to work. Many of them crashed as soon as they exec'd, too. This is why, after two years of no real progress, and no support for OSX (promised from the onset), I stopped using ZC, for six years, returning to it in 2011-ish.

 

I still use three G5 towers for graphical design, and writing. I have enough PPC laptops to stack up eight feet high. There's n real reason that ZC wouldn't run on OSX PPC, and that would allow people with old HW to use it. In fact, it could be a very inexpensive platform for ZC, in terms of HW cost, however, i have no idea if it'd run on a single G4.

 

I used to do PC development, years ago, so with regard to HW capability, a G4 is up to the task, however, some Allegro things make all non-Windows builds extremely inefficient.

 

With regard to Linux, native 64b will (likely) greatly improve that same performance issue. There's no really valid reason not to do specific binaries, either.

 

P.S. Nothing on an iPhone is 'ideal'. (I won't use a mobile without a real keyboard, either.)
 

[C-Dawg]

Going open source is great news, and I'm super happy to hear about Angelscript making things better in the future. In the interm, those of us with in-development stiff can just keep doing our thing. Maybe people will later add new functionality.

I don't really get Zora's criticism, but perhaps I don't understand what he's saying. Zscript can already do anything you want, as long as you think creatively, and this news promises even more power to come!

Thanks, devs!

[grayswandir]

I think we're using 0.3.0. I don't remember why, but I tried updating it once, and it's not trivial.

Gah, I can't find 0.3.0 anywhere. I guess I'll aim for 32bit then, see if that works.


And like I mentioned earlier, I'd really like to get my hands on the actual 2.5.2 source, so I can make quests (using a modfidied zscript compiler) that target the actual 2.5.2 engine. Having the open source is super nice, but only having access to this weird in-between beta version is kinda limiting.

[Timelord]

Going open source is great news, and I'm super happy to hear about Angelscript making things better in the future. In the interm, those of us with in-development stiff can just keep doing our thing. Maybe people will later add new functionality.

I don't really get Zora's criticism, but perhaps I don't understand what he's saying. Zscript can already do anything you want, as long as you think creatively, and this news promises even more power to come!

Thanks, devs!

 

If you want a short list, here are some of the things we plan/desire to add:

 

ZScript

 

itemdata

Add all editor values, including Attributes[10], and ensure that all item data resources, and itemdata resources cross over, including Sound, Cost, Level, and so forth.

itemdata values at present don't include about 80% of item attributes.

e.g. The values for a Peril Ring, only allow modifying its Power, but not its min_hearts. We can solve this by ensuring that all attributes are available (read/write, while we're at it).

Allow custyom itemclass definitions, and arguments via Attributes[10]

Make all values read/write.

 

*weapon

Allow easy crossing of all itemdata values. This is to allow making a weapon by reading the itemdata values of any existing item, or npcdata (see below).

Correct bomb and flag interaction with wLitBomb and wBOOM for scripted explosions, possibly adding LW_EXPLOSION as its own weapon type.

 

 

npc

Add Defences[] for all ten script types.

Ensure that all values are r/w.

Allow creation of custom npc class.

Add npc weapon attributes to match all values available to *weapon, so that the user may set them.

This includes, for example., npc->WeaponSound, npc->WeaponPower, npc->WeaponSprite, and the like.

Make all values r/w.

Give components of a segmented enemy unique flags, and allow access to them individually.

Add user-defined movement styles.

Replace(npc n) to change one npc for another, without needing to silently kill one, and spawn another.

 

npcdata: We plan to add this, to operate as itemdata for nocs, so that you can read npc values without creating them, and waiting for them to spawn.

Dynamically modify main npc attributes, such as walk type.

 

Add editor flags for various npc options, including invisibility (by type) and reveal invis (by item).

Add block flags by specific script type.

 

Link

Make all values r/w

Add Link->Extend, so that all the Link hitbox, and drawoffset, and similar things work.

Allow setting Link->Tile

Allow pre-waitdraw adjustments to Link variables that do not work at present.

Make all values r/w.

Add shield block flags to cover all script types.

 

General / Lexer

Expand the number of gd registers to a large amount.

Increase the script buffer from ~18MB to MAX_LONG in bytes.

Add additional routines for handling of strings.

Add 2D and 3D arrays.

Add special datatypes, and declarations.

Allow global datatype pointers/declarayions. This incolves preallocating some for this use, similar to arrays.

Increase array operational pointers from 4096 to *.

Increase other operational pointers for datatype objects from 255 to *.

Add extra preprocessing support.

Add some lexer symbols, such as ? (question-mark) to be used in function names, such as ?InAir()

Add function pointers.

Add custom defined datastructs.

Add a few additional types for variables.

Fix error messages to be more useful.

Detect some common errors, such as reading an invalid pointer during compilation.

Include support for linked lists and hash tables internally.

Fix combos that only work on layer 0, to work on higher layers, adding any ZScript components that we may need.

Improved sideview mode.

Add returns to detect if a screen is a dungeon, or other type, based on its DMap.

Read any DMap value.

Allow exporting the entire buffer, with all included text in-line, on compilation as a master output.

Add some directives.

Pretty much make any value read/write.

Add some mathematical things, and logical operators.

Read/set any ZC Interface options (e.g. FPS, Uncapped, MenuOpen) by script.

Fix scoping issues that cause variables declared in statements (and in the run() function) from being (improperly) pre-allocated.

Store the script id that spawns a weapon, ffc or npc with it.

 

Global

Add Subscreen namespace,and allow easy subscreen construction.

Allow datatype typecasting for objects.

Fix problem reading the pointer of a boolean array.

Read UIDs to use as pointer refs. useful for finding a specific part of a segmented enemy.

Add functions to directly modify the palette, or tiles on a pixel-basis, or colour basis, including reading tiles for a colour value.

Add internal global array series as easy to use defaults.

Internalised Remove()

Set/change quest rules by script.

 

Screen

Increase Screen->D[] regs to 256.

Add function to SetScreenBoundary() s that scrolling occurs when the player passes its event horizon, instead of the default screen edge. This would allow for different screen sizes.

Display passive subscreen as a separate option, qand set it by flag, or script.

Read/set any screen flag by script.

Read npc lists from any screen in the game.

 

Drawing

Add additional routines for bitmap handling, including translucent rendering to screen.

Increase bitmap area to a very large size (panning, scrolling)

Add missing drawing functions, such as Polygon() and Polygon3d()

Allow setting a bitmap as a texture to a drawn object.

 

ffc

Complete solidity flag, and allow it to be used with multiple types.

Add solidity bounds as variables.

 

Editor

Add flag editor.

Add font editor.

Enhance subscreen editor to support multiple pages, and other action types (equip/unequip)

Add option to use specific script object (weapon, or otherwise) in editor options that use them.

Allow setting any pulldown value to a custom value (with field for entry). For example, npc and item values.

Add additional user-defined flags, for use with flag editor.

Add SCCs for more robust options, and to complete some partially-implemented things.

Allow more than 8 script args for editor panes.

...

 

Misc.

Add 2-player, support, and multiple input device support.

Potentially find a way to solve the need to make fresh saves when changing vars, or arrays.

Add internal version detection, and reporting (when loading/playing a quest).

Change ffc loading from absolute (all screens, all DMaps at the start of the game), to a pre-emptive loading; else allow reading, and running ffcs on other screens.

Other ffc changes/improvements.

Allow 8-bit icons, and improvements to save slot/name entry/display.

Allow changing some system hardcoded colours, such as shoppe rupee prices, and death animation red flash.

Push all game save data to another quest file, for sequel support.

Fix large Link hitbox in sideview.

 

...and so on...

 

So, right, that is the short list, with our most frequently discussed ideas, or things people have repeatedly suggested, or needed.,. You might guess at some others, but none of these things are possible as-is. I'm certain I missed some critical items on our agenda, but I doubt you want to read this post for a week.

 

While you can do quite a lot with ZScript, these things would make it far more robust and friendly toward large-scope projects

Edited by ZoriaRPG, 12 February 2016 - 10:56 PM.

[SyrianBallaS]

I can't even compile the linux versions on zeldaclassic.com, it downloads but always crashes instantly. I use Ubuntu 15.10.

I looked at the Allegro4 API and it seems EXTREMELY ancient for game engine design. It's still workable though.

 

I could be wrong here, but in most cases everything that in-game is scripted.

Loading graphics, music, drawing graphics, game-engine type stuff is hardcoded. 

 

I sometimes make small games for fun using unity and it's kinda like ZC, but more like Qt.

You can drag/drop, configure things and Unity writes the code for you. Or you could script it yourself

using either C# or JavaScript.

 

Some stuff in ZC is impossible to change through scripting. Harding coding in-game objects has been abandoned

long ago in practice.

 

I think having support for at least 2D vector data types would be a nice addition for scripting.

Edited by SyrianBallaS, 07 February 2016 - 10:31 PM.

[lonegraywolf]

My reason for PPC support is personal. in fact, for years, I waited for 2.50, using my Macs. back then (2005-6), PPC was the only thing around, and there were official ZC builds for PowerPC OSX, but they were all deficient in one way or another; or merely failed to work. Many of them crashed as soon as they exec'd, too. This is why, after two years of no real progress, and no support for OSX (promised from the onset), I stopped using ZC, for six years, returning to it in 2011-ish.

 

I still use three G5 towers for graphical design, and writing. I have enough PPC laptops to stack up eight feet high. There's n real reason that ZC wouldn't run on OSX PPC, and that would allow people with old HW to use it. In fact, it could be a very inexpensive platform for ZC, in terms of HW cost, however, i have no idea if it'd run on a single G4.

 

I used to do PC development, years ago, so with regard to HW capability, a G4 is up to the task, however, some Allegro things make all non-Windows builds extremely inefficient.

 

With regard to Linux, native 64b will (likely) greatly improve that same performance issue. There's no really valid reason not to do specific binaries, either.

 

I'll put it to you like this. I plan on using cmake for project generation and development. If you can find a clean way of allowing for 10.4/10.5 PPC xcode projects to be generated, make a PR. However, I'd think the number of active PPC users is not high enough to warrant it. Besides: why should we develop for systems that are no longer maintained/active?

[SyrianBallaS]

^^

I love Cmake, use it all the time. 

If CMake supports compilers for architectures we don't develop for, those people can just use CMake.

 

Edit: This is assuming they can edit the make file for their "odd ball" system

Edited by SyrianBallaS, 07 February 2016 - 10:35 PM.

[grayswandir]

So, despite my efforts, I can't convince allegro to build its 32 bit version. Any chance the actual allegro library could be uploaded to the account as well?

[C-Dawg]

ZoraRPG, everything you're ultimately trying to do can be done with scripting, though.  I suppose that using ZScript doesn't lend itself to a point-and-click interface for others to use, and that's potentially important if you want non-programmers to make quests.  Is that the point?

[Gleeok]

You guys would laugh if I told you how I compiled ZC the first time: DN basically just threw all the source files in a single folder (Not much else) and was like "okay, here you go." ...I'm just trying say you guys have it easier than you think, and we're really not trying to be jerks.

I can't reply to much right now, but I put all the dependencies up that I forgot earlier.
I also don't even have the 2.5x branch right now (since my last laptop died) but as soon as all the random issues get sorted out we'll put them up.

[Deedee]

I can't reply to much right now, but I put all the dependencies up that I forgot earlier.
I also don't even have the 2.5x branch right now (since my last laptop died) but as soon as all the random issues get sorted out we'll put them up.

 

Okay, that sounds fair. I (and I think most of us) are in no rush.

 

 

ZoraRPG, everything you're ultimately trying to do can be done with scripting, though.  I suppose that using ZScript doesn't lend itself to a point-and-click interface for others to use, and that's potentially important if you want non-programmers to make quests.  Is that the point?

 

Transparent LttP Dark rooms are not possible without huge amounts of lag currently, as far as I am aware. Also, I, for one, am focusing mostly on non script stuff, to reduce the amount of scripting people need in Vanilla ZC.

Edited by Dimentio, 08 February 2016 - 07:29 AM.

[C-Dawg]

Transparent dark rooms; you mean like the screen is obscured except for a little window in front of the player? Sounds like you run a few dozen draw tiles on layer 6 each frame, why would that be laggy?