User Tag List

Page 3 of 3 FirstFirst 1 2 3
Results 21 to 30 of 30

Thread: I have a dream!

  1. #21
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,815
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,933
    Level
    33
    vBActivity - Bars
    Lv. Percent
    23.44%
    I see we are going with the bicker plan after all. :/ [disclaimer: I am not a psychic, but I did stay at a Holiday Inn Express last night]

    Part of the prob;em with moving c++ code to angelscript is that it's an extra layer of abstraction to work with. Debugging is harder, changes and bidings take longer, and runtime speed is slower. At the end of the day nobody really wants to deal with any of those aspects of it. That's why all new features happen in alpha stage, because hey, sometimes you don't know you don't like something until you try it.

    @ZoriaRPG : If I didn't have good reason to believe ZScript was staying around for a while and we're still 2.5 backwards compatible etc., then I wouldn't even bother updating some script functions.
    Last edited by Gleeok; 03-28-2016 at 06:06 AM.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  2. #22
    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 Gleeok View Post
    Part of the prob;em with moving c++ code to angelscript is that it's an extra layer of abstraction to work with. Debugging is harder, changes and bidings take longer, and runtime speed is slower. At the end of the day nobody really wants to deal with any of those aspects of it. That's why all new features happen in alpha stage, because hey, sometimes you don't know you don't like something until you try it. .
    Then why the hell are we doing it. Thats settle it then. We're going to have to convert the enemies and link back to cpp and implement angelscript Differently if we still which to do that. This should be fun. >_>
    Last edited by Tamamo; 03-28-2016 at 11:35 AM.

  3. #23
    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,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by Gleeok View Post
    I see we are going with the bicker plan after all. :/ [disclaimer: I am not a psychic, but I did stay at a Holiday Inn Express last night]

    Part of the prob;em with moving c++ code to angelscript is that it's an extra layer of abstraction to work with. Debugging is harder, changes and bidings take longer, and runtime speed is slower. At the end of the day nobody really wants to deal with any of those aspects of it. That's why all new features happen in alpha stage, because hey, sometimes you don't know you don't like something until you try it.

    @ZoriaRPG : If I didn't have good reason to believe ZScript was staying around for a while and we're still 2.5 backwards compatible etc., then I wouldn't even bother updating some script functions.
    (Emphasis mine.)

    That's yet another of my problems, and it toes into my qualms about solving it with a JIT compiler. Suffice to say, that we'd be trading off either performance, or platform-independence in the process. I don't particularly want to do either, but the time itself, that it'd take to go from 3.0 alpha, to something viable, may solve the performance issue, by pushing the 'typical' HW base that runs the programme toward something newer.


    Quote Originally Posted by Tamamo View Post
    Then why the hell are we doing it. Thats settle it then. We're going to have to convert the enemies and link back to cpp and implement angelscript Differently if we still which to do that. This should be fun. >_>
    I frankly think that if we follow through on our 2.future plans, it'll become easier to implement an alternative scripting engine, as what we propose will eventually turn everything important, into a variable that can be set by the user. If we can add user-defined enemy movement patterns, and some of the other goodies on our list, it might be a good stopgap between 2.5 and whatever a full rewrite--which, let's admit, is what the AS proposal is--is when completed, if completed.

    If you want to do any enemy rewrites as cpp, we'll probably use them one way or another. We absolutely need to add a few attributes to the npc class though, including a flag for 'IsCore()', and some other basic values that are missing at present. I'm thinking of adding IsPointer() to every class object, to return the pointer ID of anything as an int, and of course, the ability to reference any object by its numeric pointer; but now I'm straying off topic.
    @Dimentio is the member of our group that has interest in cleaning up the enemy code. I was going to work on the 'Talking NPC' ZC class, as requested, and I was thinking of doing some modifications to a few of the other enemy types, but it's really not part of the engine that draws my attention, or interest.

  4. #24
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,815
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,933
    Level
    33
    vBActivity - Bars
    Lv. Percent
    23.44%
    This whole thing is just getting completely ridiculous.

    First of all, any JIT compiler would not be setup unless it was running on the appropriate architecture and the user set "use_jit=1" in the config file, or was even compiled into ZC into the first place (Sorry, only x86 or x64 right now). See Also: https://github.com/BlindMindStudios/...t-JIT-Compiler

    Secondly, it's not like it's bad to put enemy code in scripts. A shitload of console games are written this way. I remember reading an article by John Carmack years ago about this (google it I guess) where he talked about the pros and cons of it. It's just that as-is it would be a nightmare for people to try and edit built-in enemy types, to say the least.

    ...That's all I feel like responding to right now.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  5. #25
    Banned
    Join Date
    May 2015
    Posts
    141
    Mentioned
    34 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    667
    Level
    9
    vBActivity - Bars
    Lv. Percent
    14.48%
    I agree, this whole thing is getting pretty ridiculous.

    I do agree on the JIT compiler. Faster processing? An option to turn it on/off? Yes please!

  6. #26
    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%
    God damn linker. Seems the zcsound library is being a cockblocker.
    If you tell me how to fix this @Gleeok I'll see what I can do about those enemies dying, willing to give it another try.
    Also appears save and load gif are't defined. I think I know why though. So I'll look into that.

    Code:
    ||=== Build: Debug Win32 in zc (compiler: GNU GCC Compiler) ===|
    ..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_stop'|
    Debug\ZC\src\build_modules\zc_subscreen_module.o:C:\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp|658|first defined here|
    ..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_unload_file'|
    Debug\ZC\src\build_modules\zc_subscreen_module.o:C:\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp|702|first defined here|
    ..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_init'|
    Debug\ZC\src\build_modules\zc_subscreen_module.o:C:\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp|175|first defined here|
    ..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_exit'|
    Debug\ZC\src\build_modules\zc_subscreen_module.o:C:\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp|263|first defined here|
    ..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_load_file'|
    Debug\ZC\src\build_modules\zc_subscreen_module.o:C:\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp|300|first defined here|
    ..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_play'|
    Debug\ZC\src\build_modules\zc_subscreen_module.o:C:\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp|457|first defined here|
    ..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_change_track'|
    Debug\ZC\src\build_modules\zc_subscreen_module.o:C:\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp|796|first defined here|
    ..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_get_tracks'|
    Debug\ZC\src\build_modules\zc_subscreen_module.o:C:\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp|767|first defined here|
    ..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_pause'|
    Debug\ZC\src\build_modules\zc_subscreen_module.o:C:\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp|573|first defined here|
    ||Warning: corrupt .drectve at end of def file|
    Debug\ZC\src\build_modules\zc_module.o||In function `main':|
    C:\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zelda.cpp|2176|undefined reference to `save_gif'|
    C:\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zelda.cpp|2176|undefined reference to `load_gif'|
    ..\..\libs\mingw\libgme.a(Spc_Emu.o):Spc_Emu.cpp|| undefined reference to `_Unwind_Resume'|
    ..\..\libs\mingw\libgme.a(Spc_Emu.o):Spc_Emu.cpp|| undefined reference to `_Unwind_Resume'|
    ||error: ld returned 1 exit status|
    ||=== Build failed: 23 error(s), 1 warning(s) (0 minute(s), 2 second(s)) ===|

  7. #27
    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,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by Dimentio View Post
    I agree, this whole thing is getting pretty ridiculous.

    I do agree on the JIT compiler. Faster processing? An option to turn it on/off? Yes please!

    You're forgetting that if we go that route, we'd need to ensure that whatever JITC we use, would be capable of converting to other architectures, like ARM, and to be prepared for needing to rewrite it repeatedly to keep up with changes. It's possible to make these very efficient, but it will never be as efficient as properly pre-compiling for the system architecture (and APIs) that you are using.

    This will not increase performance of the current ZC model. In fact, it's guaranteed to be slower than whatever we use now, even with a JIT compiler, unless we did some seriously tedious performance adjustments. If you truly want it to be fast, you need to write your own graphics handler, instead of relying on Allegro, or any of its competitors. They all pretty much sacrifice performance for versatility.

    If you want it to be insanely fast, go learn AMD64, or better yet, Power7, assembly. :p

    I'm reminded here of that cross-engine game...'Shovel Knight'. Didn't its author rewrite it in 80386 assembly, so that it was capable of running at full speed on an 80836SX-16, or something insane like that?

    For all its flaws, the popularity of Java started with the intention of having a 'fast, and efficient' cross-platform engine to run non-compiled code.

    In any case, this thing isn't going to work for Android, or iOS, and that's a prime concern for future versions of ZC, especially in terms of system processing power, and efficiency; although I'll be the first to admit that by the time we're ready to address running it on a mobile device, the power of all such devices on the (first-sale) market will have doubled.

    It also won't work on OSX, even on Intel architecture, nor so I expect support for that to come from the author. We'd need to provide it ourselves.

  8. #28
    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
    You're forgetting that if we go that route, we'd need to ensure that whatever JITC we use, would be capable of converting to other architectures, like ARM, and to be prepared for needing to rewrite it repeatedly to keep up with changes. It's possible to make these very efficient, but it will never be as efficient as properly pre-compiling for the system architecture (and APIs) that you are using.

    This will not increase performance of the current ZC model. In fact, it's guaranteed to be slower than whatever we use now, even with a JIT compiler, unless we did some seriously tedious performance adjustments. If you truly want it to be fast, you need to write your own graphics handler, instead of relying on Allegro, or any of its competitors. They all pretty much sacrifice performance for versatility.

    If you want it to be insanely fast, go learn AMD64, or better yet, Power7, assembly. :p

    I'm reminded here of that cross-engine game...'Shovel Knight'. Didn't its author rewrite it in 80386 assembly, so that it was capable of running at full speed on an 80836SX-16, or something insane like that?

    For all its flaws, the popularity of Java started with the intention of having a 'fast, and efficient' cross-platform engine to run non-compiled code.

    In any case, this thing isn't going to work for Android, or iOS, and that's a prime concern for future versions of ZC, especially in terms of system processing power, and efficiency; although I'll be the first to admit that by the time we're ready to address running it on a mobile device, the power of all such devices on the (first-sale) market will have doubled.

    It also won't work on OSX, even on Intel architecture, nor so I expect support for that to come from the author. We'd need to provide it ourselves.
    Wow... could you be any more wrong here. :-/
    How did this thread turn out like this.

    Have you even compiled ZC, ZoriaRPG? Don't lie to me here because it's missing a file.
    So quit your bitchin and let Gleeok and Saffith do there jobs.

  9. #29
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,815
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,933
    Level
    33
    vBActivity - Bars
    Lv. Percent
    23.44%
    Quote Originally Posted by Tamamo View Post
    God damn linker. Seems the zcsound library is being a cockblocker.
    If you tell me how to fix this @Gleeok I'll see what I can do about those enemies dying, willing to give it another try.
    Also appears save and load gif are't defined. I think I know why though. So I'll look into that.

    Code:
    ||=== Build: Debug Win32 in zc (compiler: GNU GCC Compiler) ===|
    ..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_stop'|
    Debug\ZC\src\build_modules\zc_subscreen_module.o:C:\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp|658|first defined here|
    ..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_unload_file'|
    Debug\ZC\src\build_modules\zc_subscreen_module.o:C:\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp|702|first defined here|
    ..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_init'|
    Debug\ZC\src\build_modules\zc_subscreen_module.o:C:\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp|175|first defined here|
    ..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_exit'|
    Debug\ZC\src\build_modules\zc_subscreen_module.o:C:\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp|263|first defined here|
    ..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_load_file'|
    Debug\ZC\src\build_modules\zc_subscreen_module.o:C:\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp|300|first defined here|
    ..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_play'|
    Debug\ZC\src\build_modules\zc_subscreen_module.o:C:\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp|457|first defined here|
    ..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_change_track'|
    Debug\ZC\src\build_modules\zc_subscreen_module.o:C:\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp|796|first defined here|
    ..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_get_tracks'|
    Debug\ZC\src\build_modules\zc_subscreen_module.o:C:\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp|767|first defined here|
    ..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_pause'|
    Debug\ZC\src\build_modules\zc_subscreen_module.o:C:\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp|573|first defined here|
    ||Warning: corrupt .drectve at end of def file|
    Debug\ZC\src\build_modules\zc_module.o||In function `main':|
    C:\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zelda.cpp|2176|undefined reference to `save_gif'|
    C:\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zelda.cpp|2176|undefined reference to `load_gif'|
    ..\..\libs\mingw\libgme.a(Spc_Emu.o):Spc_Emu.cpp|| undefined reference to `_Unwind_Resume'|
    ..\..\libs\mingw\libgme.a(Spc_Emu.o):Spc_Emu.cpp|| undefined reference to `_Unwind_Resume'|
    ||error: ld returned 1 exit status|
    ||=== Build failed: 23 error(s), 1 warning(s) (0 minute(s), 2 second(s)) ===|
    Did I just screw these up? There should be a define for that, unless you just compile zcmusic.cpp with everything else.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  10. #30
    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%
    ZCM_DLL_IMPORT is missing from the debug target I should put it back in then?
    And yes zc music is being compiled by itself... Why, i have no idea.
    I call shenanigans on the repository.

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