Jump to content

Photo

Zelda Classic 2.50.2


  • Please log in to reply
290 replies to this topic

#16 vaualbus

vaualbus

    Junior

  • Members
  • Real Name:Alberto
  • Location:Turin, Italy

Posted 23 October 2015 - 06:47 PM

Yes!

 

YES!!!

 

Saffith, you are the best guy.

And even better it would amazing if some day in the scriptis support marix and structs/classes. A lot of code would be better!

Please support them, I need for my game (for a hard script)! Ah Ah



#17 Anarchy_Balsac

Anarchy_Balsac

    Quest Builder

  • Members

Posted 23 October 2015 - 07:48 PM

And even better it would amazing if some day in the scriptis support marix and structs/classes. A lot of code would be better!

Please support them, I need for my game (for a hard script)! Ah Ah

 

If your code is so elaborate that you need structs, you're better off using canned software and C/C++/C#



#18 Shoelace

Shoelace

    The Shaman of Sexy!

  • Members
  • Real Name:Michael
  • Pronouns:He / Him
  • Location:Arizona

Posted 24 October 2015 - 12:02 PM

Wow mass coloring. I still need to recolor tons of thing so this is awesome. Thank you so much for that. I really want to try that out. :D

#19 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 25 October 2015 - 03:42 AM

And even better it would amazing if some day in the scriptis support marix and structs/classes. A lot of code would be better!

Please support them, I need for my game (for a hard script)! Ah Ah

 

This is something I've given though towards implementing, but it would not be pretty. Self-defined objects, and structs would be lovely, but making it work, with ZASM, would not. It'll require a good amount of reconfiguration, and goodness knows what would break along the way.

 

I'd like to get 2D and 3D arrays working, first. That is also daunting, because of how the bytecode works.


Edited by ZoriaRPG, 25 October 2015 - 03:43 AM.


#20 vaualbus

vaualbus

    Junior

  • Members
  • Real Name:Alberto
  • Location:Turin, Italy

Posted 25 October 2015 - 05:22 AM

This is something I've given though towards implementing, but it would not be pretty. Self-defined objects, and structs would be lovely, but making it work, with ZASM, would not. It'll require a good amount of reconfiguration, and goodness knows what would break along the way.

 

I'd like to get 2D and 3D arrays working, first. That is also daunting, because of how the bytecode works.

 

 

ya but it would be lovely. A way to solve the problem would be to remove completly ZASM. I think nowdays no body use it! 

Than you could just use a standard c++ compiler to produce either a dll (in windows) or a library for the other os. Than load it is very very simple.

Of course this will break all the script today, but you would support a standard C++ script engine!

It is a lot of work but it is possibile. 

 

By the way I also notice  that we not support array of this type:

const int TestSize = 20;

int Elements[TestSize] = ...

This should be very easy to implement as soon as the size is constant.

 

Edited by vaualbus, 25 October 2015 - 05:25 AM.


#21 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 25 October 2015 - 12:23 PM

 

 

ya but it would be lovely. A way to solve the problem would be to remove completly ZASM. I think nowdays no body use it! 

Than you could just use a standard c++ compiler to produce either a dll (in windows) or a library for the other os. Than load it is very very simple.

Of course this will break all the script today, but you would support a standard C++ script engine!

It is a lot of work but it is possibile. 

 

By the way I also notice  that we not support array of this type:

const int TestSize = 20;

int Elements[TestSize] = ...

This should be very easy to implement as soon as the size is constant.

 

 

That would be much more difficult than you think... ZScript is a ZASM interface. It compiles into ZASM, and the bytecodes are stored in an array, as words; then read and parsed by the engine via opcodes that reference those words, via strings and arrays listing the properties. It's pretty 'dirty', and removing ZASM would be tedious. It would be easier to expand ZASM, and to add another interface, such as AngelScript, that compiles down to it.

 

Standard C, as I recall, doesn't support constant matching to array declaration. That's a C++ thing. Not that I disagree, as it'd be useful; as would mathematical declaration:

 

float myArray[12+190-16+(2^8)];

 

At least, that would be useful, to me, and a select few others.

 

I think that's all a good topic for a separate thread though, as I don;t particularly want to clog up Saffith's topic with feature requests for a version that will be a year or more in the making.

 

If you want to make a ZScript/ZASM feature request thread, please do so, and I'll read any suggestions, and requests, and stack those that are possible onto my list. I won't commit to making your dreams come true, but I'll give it the old school try.

 

There are some other things I'd like to get into a future version, post o-s release; many of which were requested on AGN. You may want to sign up over there too, as there is a ZC/ZQ Feature Requests forum, there.

 

P.S. My first priories for ZASM/ZScript for 2.55+ are:

 

Spoiler

 

Again, if you want to discuss this, a new thread would be best. Call it  and ZScript Feature Requests for the Future, or something like that.

 

---

 

In other news, the support files for 2.50.2 are almost done; pending dev approval. That includes new zscript.txt, std.zh, string.zh, and similar files. I finished std_constants.zh for 2.50.2+ the other day--or at least, I believe it is finished--and that leaves std,txt to complete. 

 

Once those are all done, I'll start working on making an (indexed) PDF of zscript.txt, string.txt, std,txt, zstrings.txt, and the main docs. That means breaking out FM11, and making a real manual, which is time-consuming, but it'll be very useful, and easy to use.



#22 Alucard648

Alucard648

    Wizard

  • Members
  • Location:castle Dracula

Posted 25 October 2015 - 01:54 PM

Speaking for ZScript expansions, I wish for following functions:

1. Screen->SecretCombos[] Direct way to access screen`s secret combos, read & write. While working on stdWeapons.zh, I always missed one thing: when a combo with flag 16-31 would be replaced with screen`s undercombo, it`s replaced with approriate screen`s secret combo instead. I have tried to re-script this behaviour with stdCombos.zh and found out there is no way to access secret combos from scripts at all.

2. Npc->Miscflags to be writable. It`s illogical, why there are no proper way to have regenerating enemy shields? 

3. Link/npc/*weapon/item->Tile to be writable. Setting this variable would change object`s tile until next Waitframe(), where it is rendered with tile chosen. Again for custom animations.

4. Some blank Link`s actions for scripting purposes.

 

And, of course, expanding number of blank combo types and flags is greatly helpful.


Edited by Alucard648, 25 October 2015 - 01:54 PM.


#23 ywkls

ywkls

    Master

  • Members

Posted 26 October 2015 - 01:23 AM

I think I may have found a bug with the new version. When I downloaded it and loaded my scripts, every one of them worked properly... except InvertedCircle from stdExtra.zh. 

 

This draws a transparent circle at the coordinates of your choice and fills the rest of the screen with a color of your choice on a layer. For some reason, the center of the circle is not being drawn where the script says it should be and the portion that is supposed to be changed to a specific color is offset from the top of the screen.

 

I have no other clues about what is causing this, since that's the only thing which has changed since the last time I tested this script. (When it worked fine.)

 

Here's the script for the InvertedCircle function and how I'm using it in my quest.

void InvertedCircle(int bitmapID, int layer, int x, int y, int radius, int scale, int fillcolor){
    Screen->SetRenderTarget(bitmapID);     //Set the render target to the bitmap.
    Screen->Rectangle(layer, 0, 0, 256, 176, fillcolor, 1, 0, 0, 0, true, 128); //Cover the screen
    Screen->Circle(layer, x, y, radius, 0, scale, 0, 0, 0, true, 128); //Draw a transparent circle.
    Screen->SetRenderTarget(RT_SCREEN); //Set the render target back to the screen.
    Screen->DrawBitmap(layer, bitmapID, 0, 0, 256, 176, 0, 56, 256, 176, 0, true); //Draw the bitmap
}

In quest...

InvertedCircle(4, 6, Link->X+8, Link->Y+8, 32, 1, 15);

Any help at resolving this would be greatly appreciated!



#24 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 26 October 2015 - 02:08 AM

I think I may have found a bug with the new version. When I downloaded it and loaded my scripts, every one of them worked properly... except InvertedCircle from stdExtra.zh. 
 
This draws a transparent circle at the coordinates of your choice and fills the rest of the screen with a color of your choice on a layer. For some reason, the center of the circle is not being drawn where the script says it should be and the portion that is supposed to be changed to a specific color is offset from the top of the screen.
 
I have no other clues about what is causing this, since that's the only thing which has changed since the last time I tested this script. (When it worked fine.)
 
Here's the script for the InvertedCircle function and how I'm using it in my quest.

void InvertedCircle(int bitmapID, int layer, int x, int y, int radius, int scale, int fillcolor){
    Screen->SetRenderTarget(bitmapID);     //Set the render target to the bitmap.
    Screen->Rectangle(layer, 0, 0, 256, 176, fillcolor, 1, 0, 0, 0, true, 128); //Cover the screen
    Screen->Circle(layer, x, y, radius, 0, scale, 0, 0, 0, true, 128); //Draw a transparent circle.
    Screen->SetRenderTarget(RT_SCREEN); //Set the render target back to the screen.
    Screen->DrawBitmap(layer, bitmapID, 0, 0, 256, 176, 0, 56, 256, 176, 0, true); //Draw the bitmap
}
In quest...
InvertedCircle(4, 6, Link->X+8, Link->Y+8, 32, 1, 15);
Any help at resolving this would be greatly appreciated!

 


Screenshot, please, in 2.50.0/1, and 2.50.2. I believe that the subscreen offset fixes are the cause:

 

Fixed a bug where scripts drawing to bitmaps before drawing to a screen layer un-offset the sub-screen offset causing them to be rendered in wrong position on screen. ( Gleeok, 2015-03-25 09:43:09 )

 

Temporary Fix

In stdExtra.zh, change DrawInvertedCircle() as follows:

Replace:
 

 Screen->DrawBitmap(layer, bitmapID, 0, 0, 256, 176, 0, 56, 256, 176, 0, true); //Draw the bitmap

...with...
 

 Screen->DrawBitmap(layer, bitmapID, 0, 0, 256, 176, 0, 0, 256, 176, 0, true); //Draw the bitmap

If it is that '56' offset, then that will need a quest rule fix, and almost all of the possible QRs are in use. Note that this fix will break games for 2.50.0/1, and (2.50.0/1)  games that use DrawInvertedCircle() , or other functions that use DrawBitmap() with RT_SCREEN may (respectively) all exhibit this problem.

 

QR Suggestion: Offset Subscreen when Drawing Bitmaps (disabled by default)

 

Note to Saffith: If we had a way to read the ZC build ID from scripts, we wouldn't need a QR for this sort of problem; so that'd be good idea for the future.


Edited by ZoriaRPG, 26 October 2015 - 02:49 AM.


#25 Lejes

Lejes

    Seeker of Runes

  • Members
  • Location:Flying High Above Monsteropolis

Posted 26 October 2015 - 02:09 AM

Probably has something to do with this.

 

 

 

* Fixed a bug where scripts drawing to bitmaps before drawing to a screen layer un-offset the sub-screen offset causing them to be rendered in wrong position on screen. 

 

Try changing the dest_y argument in DrawBitmap from 56 to 0.



#26 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 26 October 2015 - 02:56 AM

Probably has something to do with this.

 

 

Try changing the dest_y argument in DrawBitmap from 56 to 0.

 

This is what happens when I float posts in edit mode, to make them perfect. I mentioned that when I first filed the post, and then wrote out an example, and detailed instructions for fixing it; along with documenting the problem. It's going to be a rather large one, because many games use that function from stdExtra.zh , even if the questmaker doesn't know it. :P

 

Apparently, the breaks to do other things were long enough for forty minutes to pass?!

 

That is indeed the cause, though, which only further necessitates a 2.50.3 Gamma. Releasing a second 2.50.2 would only be a point of confusion for users.


Edited by ZoriaRPG, 26 October 2015 - 02:59 AM.


#27 Gleeok

Gleeok

    It's dangerous to dough alone, bake this.

  • Members
  • Real Name:Pillsbury
  • Location:Magical Land of Dough

Posted 26 October 2015 - 03:46 AM

This is what happens when nobody bothers to post a bug report and instead adds it to an open library that relies on the bug for people to use. By the time I even came across some random post here where someone was having trouble getting it to work 2.5 was already released for 2 years. :angry:

There's certainly no chance for a quest rule though (that would be ridiculous). The only other option is to just put the bug back in where sometimes you'd need to offset it, and sometimes you don't... Not particularly good IMO. So... yeah... I don't know.

#28 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 26 October 2015 - 04:27 AM

This is what happens when nobody bothers to post a bug report and instead adds it to an open library that relies on the bug for people to use. By the time I even came across some random post here where someone was having trouble getting it to work 2.5 was already released for 2 years. :angry:

There's certainly no chance for a quest rule though (that would be ridiculous). The only other option is to just put the bug back in where sometimes you'd need to offset it, and sometimes you don't... Not particularly good IMO. So... yeah... I don't know.

 

Clarify... Why would a QR for compatibility be a problem? I don't see a benefit of intentionally reverting it, versus a QR, other than the QR wasting a bit. We have quest rules for compatibility with other bugs, such as weapons without collision, after all.

 

What about determining if a quest was created in 2,50.0/1 versus 2.50.2; and then automating the DrawBitmap method based on that? That should work, as the ZQ version is stored in the quest header, and you can just use a paired if/else statement with both versions of the code.

 

I also believe this will affect Tango.zh.

 

P.S. To be fair, it;s occasionally difficult to determine if something is a bug, versus intentional. Why it was never reported, I've no idea. Probably because there is no bug report board here, and because the documentation on using bitmaps is almost non-existent.


Edited by ZoriaRPG, 26 October 2015 - 04:42 AM.


#29 kurt91

kurt91

    Follower of Destiny

  • Members
  • Real Name:Kurtis
  • Location:Eastern Washington University

Posted 26 October 2015 - 04:50 AM

I don't know a better place to ask, but...

 

Apparently there's another site that's doing an online game expo soon and is looking for submissions. I was wondering if it would be okay if I included a copy of ZC with my quest, since it's not a ZC site, and I don't know how well it would go over having to give extra links and directions just to be able to play a demo submission. I thought it would be easier to just zip together a copy of ZC, a copy of my quest demo, and directions on how to load the quest into ZC. Is that alright?



#30 ywkls

ywkls

    Master

  • Members

Posted 26 October 2015 - 10:02 AM

Yes, that line in stdExtra.zh was indeed the cause of the bug that I was experiencing. Which means that for my quest to work as it is currently scripted, it would have to be played in 2.5.2 to work properly. Anything else would just look wrong.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users