User Tag List

Page 2 of 4 FirstFirst 1 2 3 4 LastLast
Results 11 to 20 of 39

Thread: 2.x vs 3.x

  1. #11
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    @Saffith ,
    How come you rolledback your changes to the item logic. Specifically the hookshot for example.
    With the changes to UID handling that means the patra and manhandla bugs are broken because the new code isn't in yet.
    As for FFC flags that have come to my concern.
    • ffSWAPNEXT seems bugged btw. I think it's if condition statement is checking for the wrong flag, it checks for ffSWAPPREV. Also yeah we should probably change it so they only effect speed. Ugh... probably gonna need a quest rule for it though.
    • ffCHANGESPEED: We could still get that implemented, but i personally think it's way too much trouble unless people seriously want to have that feature. It's still up in the air and you probably agree.
    • ffSOLID: Not happening, I'm not going through that hell again, god only knows wtf it would break if not ZC itself.


    @ZoriaRPG
    That sounds like a LSD trip actually, mhm....

    @Gleeok
    If I was to ask you kindly to rewrite ffc so we can 64 for per screen would you do it?

  2. #12
    Is this the end?
    ZC Developer
    Saffith's Avatar
    Join Date
    Jan 2001
    Age
    41
    Posts
    3,389
    Mentioned
    178 Post(s)
    Tagged
    6 Thread(s)
    vBActivity - Stats
    Points
    6,451
    Level
    24
    vBActivity - Bars
    Lv. Percent
    73.19%
    How come you rolledback your changes to the item logic. Specifically the hookshot for example.
    The goal for the existing objects should be to move them out of the way without making major changes to their behavior. A bit of cleanup is okay, but those went too far. And they weren't really a great way of doing things in the first place.

    If I was to ask you kindly to rewrite ffc so we can 64 for per screen would you do it?
    As they are now, that's a lot of additional memory usage - about another megabyte per map. Maybe if they're reworked a bit.

  3. #13
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,827
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,978
    Level
    33
    vBActivity - Bars
    Lv. Percent
    28.3%
    Quote Originally Posted by Tamamo View Post
    @Gleeok
    If I was to ask you kindly to rewrite ffc so we can 64 for per screen would you do it?
    No. Too much other stuff gets priority. I'd never get around to it.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  4. #14
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,781
    Level
    21
    vBActivity - Bars
    Lv. Percent
    73.04%
    Quote Originally Posted by Tamamo View Post
    @Saffith ,
    How come you rolledback your changes to the item logic. Specifically the hookshot for example.
    With the changes to UID handling that means the patra and manhandla bugs are broken because the new code isn't in yet.
    As for FFC flags that have come to my concern.
    • ffSWAPNEXT seems bugged btw. I think it's if condition statement is checking for the wrong flag, it checks for ffSWAPPREV. Also yeah we should probably change it so they only effect speed. Ugh... probably gonna need a quest rule for it though.
    • ffCHANGESPEED: We could still get that implemented, but i personally think it's way too much trouble unless people seriously want to have that feature. It's still up in the air and you probably agree.
    • ffSOLID: Not happening, I'm not going through that hell again, god only knows wtf it would break if not ZC itself.


    @ZoriaRPG
    That sounds like a LSD trip actually, mhm....

    @Gleeok
    If I was to ask you kindly to rewrite ffc so we can 64 for per screen would you do it?
    Giving up on ffSOLId already, are we? Not that I blame you.

    Without some kind of general memory management, ffcs can't be increased like that. They are the single biggest RAM sink in all of ZC. Note that nobody wants to rewrite them... We'd be better off making a new class of objects that behaves like them, but is called only on demand.

  5. #15
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,827
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,978
    Level
    33
    vBActivity - Bars
    Lv. Percent
    28.3%
    Quote Originally Posted by ZoriaRPG View Post
    Giving up on ffSOLId already, are we? Not that I blame you.

    Without some kind of general memory management, ffcs can't be increased like that. They are the single biggest RAM sink in all of ZC. Note that nobody wants to rewrite them... We'd be better off making a new class of objects that behaves like them, but is called only on demand.
    There's a few ideas for them. I'm probably just leaning towards a simple FFCMemoryPool since the total number of ffcs is known at quest load time, and then a single ScreenFFC object. Naively, mapscreen would then need 64 bytes of indices to ffcs instead of whatever it is now; you can get rid of that also but it's already going to be a pain in the ass updating ZQuest so I'd call 64 bytes a big win.


    I suppose allowing 256 FFCs on screen at a time isn't that difficult either, provided that FFCs 32 - 255 can only be created directly with scripts... although I'll have to double-check the workings of ffc stuff because I can't remember atm.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  6. #16
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,781
    Level
    21
    vBActivity - Bars
    Lv. Percent
    73.04%
    Quote Originally Posted by Gleeok View Post
    There's a few ideas for them. I'm probably just leaning towards a simple FFCMemoryPool since the total number of ffcs is known at quest load time, and then a single ScreenFFC object. Naively, mapscreen would then need 64 bytes of indices to ffcs instead of whatever it is now; you can get rid of that also but it's already going to be a pain in the ass updating ZQuest so I'd call 64 bytes a big win.


    I suppose allowing 256 FFCs on screen at a time isn't that difficult either, provided that FFCs 32 - 255 can only be created directly with scripts... although I'll have to double-check the workings of ffc stuff because I can't remember atm.
    255, I suppose you mean, as ffc 0 is NULL. I'm perfectly fine with them being script-created, as the general application for them is for script-created objects. Sounds quite good, in fact.

    For ffc solidity, i was thinking that giving ffcs a (separate) hitbox, and adding hitwidth, hitheight, hitoffset, and such, would allow setting ffSOLID as a simple flag, treating the hitbox of the ffc as a solid object. That would allow the user some freedom in making the ffc partially solid, without turning ffc solidity into a disaster.

    Keeping this separate from EffectWidth/Height and such would be critical.

  7. #17
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    Quote Originally Posted by ZoriaRPG View Post
    Giving up on ffSOLId already, are we? Not that I blame you.

    Without some kind of general memory management, ffcs can't be increased like that. They are the single biggest RAM sink in all of ZC. Note that nobody wants to rewrite them... We'd be better off making a new class of objects that behaves like them, but is called only on demand.
    It's more so how much stuff require the 8x8 grid to function correctly. Link, certain weapons, enemies, a couple combos (none of which actually work as ffcs) rely on the grid to function correctly.

    addendum...
    About the fCHANGESPEED flag, since that is the default we could make the flag do the opposite actually that is to say, prevent it from happening. That way you can simply change the combo/cset when it touches a changer and not have to keep track of it's speed. "Which would be good for a ffc that decelerates."
    Last edited by Tamamo; 07-11-2016 at 03:31 PM.

  8. #18
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    edit: Fixed
    Last edited by Tamamo; 07-12-2016 at 10:34 AM.

  9. #19
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    @ZoriaRPG
    I think ffcs are almost done, all that is left to do is figure out what to do about the Change Speed flag.
    @Saffith
    IIRC Link's tile is determined when he is drawn. Since that is the case, we could just abstract (more layers of that shit. Just what we don't need) Link's drawing code into it's own file. Thoughts? Also have we decided how we're going to handle the UIDs yet? Manhandla and Patra are still broken lol.
    @Gleeok
    So I've been thinking of refining the weapons so they're object-oriented and don't make use of a bunch of damn switch statements. That was a terrible idea btw. The code for weapons however is such a clusterfuck I'm about ready to just rewrite them from scratch. You okay with this?
    Last edited by Tamamo; 07-12-2016 at 01:55 PM.

  10. #20
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,781
    Level
    21
    vBActivity - Bars
    Lv. Percent
    73.04%
    Quote Originally Posted by Tamamo View Post
    @ZoriaRPG
    I think ffcs are almost done, all that is left to do is figure out what to do about the Change Speed flag.
    @Saffith
    IIRC Link's tile is determined when he is drawn. Since that is the case, we could just abstract (more layers of that shit. Just what we don't need) Link's drawing code into it's own file. Thoughts? Also have we decided how we're going to handle the UIDs yet? Manhandla and Patra are still broken lol.
    @Gleeok
    So I've been thinking of refining the weapons so they're object-oriented and don't make use of a bunch of damn switch statements. That was a terrible idea btw. The code for weapons however is such a clusterfuck I'm about ready to just rewrite them from scratch. You okay with this?
    I'm also going to need a breakdown of the new UID system.

    I was thinking of adding OriginalTile to Link so that we can change his tile reliably. Does that sound fair?

    ffcs almost done... I wish. If Gleeok manages to add that memory pool stuff, hell yes. Not sure how to resolve grid issues. I think we'd need a whole extra set of CanWalk and other checks just for ffc solidity, and I still want to add hitboxes.

Thread Information

Users Browsing this Thread

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

Tags for this Thread

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