Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - TheExDeus

346
Proposals / Re: Allow me to use C++ in EDL
« on: November 23, 2014, 12:51:56 pm »
Yes, headers are the biggest problems. But you can put classes inside the .cpp file as well and it's valid. You wouldn't be able to use templates though (they are purely a header thing). My idea was that this is a script. So everything goes in one script resource, which I then call. The problem of not parsing a whole "file" is that you then can't actually access neither local or global variables (for which parser generates accessors). So you can't actually do anything in that code that can be used elsewhere in the program. That is why I suggest some syntax, that allows me to select which part is parsed and which is ignored. So I can run fast code in C++, then give result back to an instance via EDL.

347
Proposals / Allow me to use C++ in EDL
« on: November 23, 2014, 06:06:05 am »
I kind of hate GM datastructures. They are slower, harder to use and harder for compiler to optimize, because they are a wrapper. I would want to use STL containers, like vectors and lists. Can we finally make it happen? It's probably a parser thing again, but could it be possible in the short term to just add a language syntax to allow C++, like "{C++} { }". I know Josh already though about something like it, but I want to know how complicated would it be? Basically I want everything inside {C++} to NOT be parsed and taken as valid C++. Then every variable inside that scope to be temporary to the script (it should happen by default), so I can access it. Like for example:
Code: (c++) [Select]
{C++}{
#include <vector>
using std::vector;

class myClass{
 double value;
};

vector<myClass> myVector;
for (auto &cl : myVector){
  cl.value = 3.1415;
}
 
}

//This is parsed EDL
for (unsigned int i=0; i<{C++}{myVector.size();} ++i){
  ds_grid_set(grid, i, 0, {C++}{myVector.value});
}

This is very ugly, but the point is that I plan to make a very high performing part in pure C++ and then only copy the results back to EDL for drawing.
This way we don't need to wait for a new parser for 10 years, but get a "patch" that could potentially be easy to implement.
Any ideas?

348
Developing ENIGMA / Re: Massive GL3.3 changes.... again
« on: November 17, 2014, 07:37:45 pm »
I don't think it can be fixed with glViewport and scissor functions. Here it requires the matrix to be changed and there is a problem. I can change the d3d_set_projection_ortho() in surface_set_target from "d3d_set_projection_ortho(0, 0, surf->width, surf->height, 0);" to "d3d_set_projection_ortho(0, surf->height, surf->width, -surf->height, 0);" and it will work fine. But then whenever the user tries to do anything with the matrices that require an identity (like d3d_set_projection_scale()), then he will have to manually flip it again. So this will fix many cases, but not all. Now sure what to do. I think this is basically the modification I wanted previously, but we used gl matrices previously, so we didn't want this solution (glScale(1,-1,1) looked ugly).

edit: Good news is that the shadow example here (http://enigma-dev.org/edc/games.php?game=62) actually works faster now. Previously in GL1 it was 2285FPS. Now it's about 2350FPS in GL1.1 and 2810FPS in GL3.3 (with all the lights placed in the same positions). So we have improved.

349
Developing ENIGMA / Re: LateralGM 1.8.6.828
« on: November 14, 2014, 05:49:21 am »
Quote
* Save and load dialog warnings do not recognize extensions and file filters are not consistent among a lot of dialogs, needs cleaned up and fixed.
I hope this involves checking why Save As has two places specify the format to use. It always bugged me. Ism mentioned something about it years ago, but I don't remember if it was in defense for that decision or not. Right now I don't know which of them are actually used, or even if both somehow is. So I always have to click the radio button "egm" together with dropdown menu "egm". Also, "egm" should probably be the default choice and be at the top.

350
Developing ENIGMA / Re: LateralGM 1.8.6.828
« on: November 14, 2014, 03:03:16 am »
Quote
Does the error only happen when loading this specific EGM? Try loading a GMK or GMX or open ENIGMA without opening that EGM.
No, I don't even load anything. It happens right when opening LGM.

edit: Jup, just as I thought. The problem is that I had an error in an include.h file. Instead of "gui_button_get_style(int id);" I got "gui_button_get_style(int id){", which broke the parser and then the error message (I think it was the error message) then broke LGM, because the error message needed some fancy borders or something. I think the parser shouldn't segfault on syntax errors like that. Josh (or anyone else doing parser stuff) should look into that.

351
Developing ENIGMA / Re: LateralGM 1.8.6.825
« on: November 13, 2014, 07:20:15 pm »
Quote
1) Have you updated both enigma.jar and lateralgm.jar? Because it looks like your engima.jar is out of date, the reported line numbers are incorrect.
Yes. I downloaded the enigma.jar from wiki. I just did it again, but the same problem (as it's still 5 days old).

Quote
2) What is the window decorations preference set to under "Appearance"?
I have it turned off. I just enabled it and same problem. Then I turned it off again.

Quote
3) What is hardware acceleration set to?
Off.

The problem actually started before I upgraded. I just though upgrading might fixed it. It started for no apparent reason while I was editing an .egm and making the gui extension. The "Memory access violation" made me think the problem could be a lot deeper, like parsing one of the files I changed. But the stack trace doesn't show anything like that, so I don't know.

352
Developing ENIGMA / Re: LateralGM 1.8.6.823
« on: November 13, 2014, 05:02:55 pm »
For some reason with the newest LGM I get constant crashes (I think the plugin crashes, as I cannot select anything in the ENIGMA menu only).
http://pastebin.com/tmqjBXWG
http://pastebin.com/Y8bBhFep
It shows that on startup. I don't have to do anything.

353
Developing ENIGMA / Re: Massive GL3.3 changes.... again
« on: November 10, 2014, 11:54:01 am »
Quote
Oh, I certainly don't see it. Is there a way to change the zoom level? The default view starts out very zoomed-in.
Zoomed in? You should be able to move with WASD and look around with mouse. The FOV doesn't seem to be really wrong in your screenshot, but it's hard to tell.

Quote
I would like to add Harri that I am planing on wrapping up LateralGM 1.8.7 soon after some additional fixes and integration of other new features.  I would like to have the OpenGL fixes in so that I can also fix the Direct3D surfaces. But we should decide on whether we want to add a draw_set_viewport function that does not scale the viewport and a screen_set_viewport that does scale the viewport to screen scaling coordinates or perhaps just add a booelean scaleToWindow to the existing function. But anyway I would like the GL3 fixes to be finalized so it can also be included in the new Portable ZIP alongside sorlok's array length functions and the new LGM.
I'm not sure either. I think either way is fine if by default it works like it should. You can then allow users to call those functions as well, but not sure what use they really would have. In my mind when you bind a surface, it should have the surface as the viewport, so you can draw on it like you would on screen. And draw like on an arbitrary size monitor. If a person wants a different viewport or projection, then he should set that AFTER binding the surface. Just like GM.

354
Developing ENIGMA / Re: Massive GL3.3 changes.... again
« on: November 09, 2014, 04:44:54 pm »
Like the screenshot in the original topic:

355
Issues Help Desk / Re: Can someone help me I have a question
« on: November 09, 2014, 03:59:53 pm »
ENIGMA doesn't have loading bars of any kind. LGM should let you change them, in case you just want to modify a regular GM project, but ENIGMA doesn't use any of that. So it could be a bug.

356
Developing ENIGMA / Re: Massive GL3.3 changes.... again
« on: November 09, 2014, 01:55:55 pm »
Compile in debug mode and try "gdb compiled_game.tmp" and see where the segfault happens. For me it happened in "surface_reset_target()" because the driver I was using inside the VMWare didn't support much. Another thing was loading and using resources. Project Mario tries to play some audio resources it doesn't load, so if there is no "== -1" checks, then it crashes at that screen. I did add those checks to audio system however. Also, when running mario you must do it from the directory where all the mario files are.

Is the glass cube in shader example also visible? I'm not sure what would cause the tearing. Maybe flickering on the glass surface, but not tearing.

357
Developing ENIGMA / Re: LateralGM 1.8.6.762
« on: November 06, 2014, 07:39:27 am »
Quote
What are you saying Harri? That you want to type in "obj_player" and have it find it in the tree? It already does that... That other menu has already become deprecated basically, just not removed, I am leaving it there because some people from old GM's may be upset when they look for it and can't find it. It can stay around until it gets stale.
Yeah, you are right. I was waiting the result to be in "Search results" tab though. So when I search for "spr_", then in search results all resources with spr_ would also be listed. Not only code.

I have a bug that LGM sometimes freezes when I press the green compile button. Usually I can compile one time, then the second time it will freeze and stop. Other times it will freeze on the first try. Nothing gets written in the log. The only way to close LGM is to use task manager.

edit: It has also crashed once for me (the whole Java runtime), but it doesn't seem print any errors anywhere. So it has gotten a lot more unstable for me too.

358
Developing ENIGMA / Re: LateralGM 1.8.6.76
« on: November 05, 2014, 04:47:09 pm »
Another thing you could add is searching resources themselves with the same search box. There is already a resource->find option in LGM, but it would be better to have it in the same tree style. Then that option could be removed.

359
I can't get this to work in ENIGMA. I added this to var4.h:
Code: [Select]
//For RTTI
namespace enigma{
  struct reference_index {
    int id;
    reference_index(int idx): id(idx) {}
    enum { DNE = -1 };
  };
 
  template<class T> struct derived_reference_index: reference_index {
    derived_reference_index(): reference_index(-1) {}
    derived_reference_index(int idx): reference_index(idx) {}
  };
 
  namespace RTTI {
    template<class T> int compiler_ids();
  }
}

struct variant
{
template<class T> variant(const enigma::derived_reference_index<T>& dri): rval(dri.id), sval( ), type(enigma::vt_real), rtti(enigma::RTTI::compiler_ids<T>()) { }
}
Then I modified var4.cpp to have this:
Code: [Select]
variant::variant(const variant& x): rval(x.rval.d), sval(x.sval), type(x.type), rtti(x.rtti) { }
variant::variant(const var& x): rval((*x).rval.d), sval((*x).sval), type((*x).type), rtti((*x).rtti) { }
variant::variant(): rval(0), sval( ), type(default_type), rtti(-1) { }
In my extension's include.h:
Code: [Select]
namespace enigma {
  namespace RTTI {
    enum variant_runtime_types {
      VRT_WINDOW, 
      VRT_BUTTON
    };
   
    //template<> int compiler_ids<enigma_user::window_t>() { return VRT_WINDOW; }
    template<> int compiler_ids<enigma_user::button_t>() { return VRT_BUTTON; }
  }
}
And button create:
Code: [Select]
variant gui_button_create(){
if (gui::gui_bound_skin == -1){ //Add default one
gui::gui_buttons.insert(pair<unsigned int, gui::gui_button >(gui::gui_buttons_maxid, gui::gui_button()));
}else{
gui::gui_buttons.insert(pair<unsigned int, gui::gui_button >(gui::gui_buttons_maxid, gui::gui_buttons[gui::gui_skins[gui::gui_bound_skin].button_style]));
}
gui::gui_buttons[gui::gui_buttons_maxid].visible = true;
gui::gui_buttons[gui::gui_buttons_maxid].id = gui::gui_buttons_maxid;
return variant(enigma::RTTI::button_t(gui::gui_buttons_maxid++));
}
And I get this:
Code: [Select]
Universal_System/Extensions/BasicGUI/buttons.cpp: In function 'variant enigma_user::gui_button_create(gs_scalar, gs_scalar, gs_scalar, gs_scalar, std::string)':
Universal_System/Extensions/BasicGUI/buttons.cpp:195:65: error: no matching function for call to 'enigma::RTTI::button_t::button_t(unsigned int)'
   return variant(enigma::RTTI::button_t(gui::gui_buttons_maxid++));
                                                                 ^
Universal_System/Extensions/BasicGUI/buttons.cpp:195:65: note: candidates are:
In file included from Universal_System/Extensions/BasicGUI/buttons.cpp:34:0:
Universal_System/Extensions/BasicGUI/include.h:33:12: note: enigma::RTTI::button_t::button_t()
Among a lot of other things. I have tried about 3 hours to fix this without luck. The best I had was "multiple definitions" linker error.

The problem is that your example is self contained, but in ENIGMA I need the var4 changes to work even if my extension is disabled. And as nothing is generated right now, then I need to add this manually in extensions instead of main ENIGMA:
Code: [Select]
namespace enigma {
  namespace RTTI {
    enum variant_runtime_types {
      VRT_WINDOW, 
      VRT_BUTTON
    };
   
    //template<> int compiler_ids<enigma_user::window_t>() { return VRT_WINDOW; }
    template<> int compiler_ids<enigma_user::button_t>() { return VRT_BUTTON; }
  }
}
It seems for now I will make the extension without this, but I really would want this. That would greatly reduce my function count, as I would have "gui_element_sprite" instead of "gui_button_sprite", "gui_window_sprite", "gui_slider_sprite" and so on.

360
Developing ENIGMA / Re: Massive GL3.3 changes.... again
« on: November 04, 2014, 02:41:40 pm »
Alright. I just reverted the xlib changes. Now please try again. I have installed Ubuntu on a virtual machine, but sadly, that doesn't allow me to use new graphics functionality, as the gpu is virtual as well. So I ended up without GL2.1 support max. But I could compile it without errors and run GL1.1 until surfaces were used. Then it breaks, as the virtual driver doesn't support framebuffers.

So on Linux try all the examples, but ignore minecraft bug, as there is a problem in draw_getpixel, not drawing itself. I will try to get ubuntu somehow going (I guess in dual boot) and try testing again.

Can everyone please test this, hopefully, final version? It works for me on Nvidia and AMD.