Menu

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.

Show posts Menu

Messages - linky

#1
Bravo fosamax ! The thread you found corresponds exactly to my problem :

"if Qt library is compiled with SSE2 and machine does not have the SSE2 support, your Qt application will crash with "The application failed to initialize properly "0xc000001d"" error message."

I didn't knew that the Solarus editor was made with QT and unfortunately i have never used this framework, so there is probably not much things to do. At least I have a clear explanation on the origin of the problem, c'est déjà ça.

Thank you
#2
Hi fosamax,

The problem is that it's not for only one pc but for about 10 used in a classroom that have exactly the same old hardware. I could probably change one by myself, but this wouldn't be usefull to get only one which works with Solarus 1.4.2 and the other with the previous version. And anyway it would be a pity to change all of them for the moment as they works sufficiently well for some other development tools like visual studio express 2010 that students can use without problem, just a litle bit slow as you can imagine.
#3
I think you really shouldn't change anything about the development of solarus code just for this very particular problem, that i am probably the only one to encounter. This configuration is clearly completely outdated, but unfortunately it's not depending on me to renew the computer hadware, so i will continue with version 1.3.1.

I had choosen Solarus some times ago to teach lua in this very nice and funny game environment, especially because it don't ask big resources and the last graphic card uptodate. But if it's no more possible to keep compatibility with older machine, from my point of view, there isn't any hesitation to have and you should continue in this direction. It wouldn't be reasonable to limit the potential of solarus for that specific situation. In particular because it is apparently not a problem with XP that is still widely used (like froggy77 & me), but only with too old processors.

I just wished to know if there was a way i could maybe myself (with my small dev skill) recompiled the solarus code or something like this to make a version on my own without some components by unchecking this or that somewhere, that can allow it to run on low configuration, but apparently it is not the case. This was the big advantage of the previous java version that could run everywhere without problem, but things have to go on.

Thank's anyway
#4
Thank you all for your help !

I have check today and the configuration is the same as froggy77 :

XP (familly) SP3 with directX 9.0c and all framework .net 2, 3.5 and 4.5 installed with SP pack when there is. Everything is with last update avalaible, so i don't think the problem comes from there.

The event viewer of windows shows this error message, but says nothing more about its origin.

Searching more precisely on google show me that this error code (0xc000001d) is often associated with problem in games application and are explained by the fact that the processor is too old and don't propose SSE2 instructions set. I have check with CPU-Z and the processor of those old pc are :

AMD Athlon(tm) Barton XP 2800+ (Socket A (462))
Instructions sets:  MMX (+), 3DNow! (+), SSE
(its really old PCs but still runing :) )

so doesn't support SSE2.

Do you think that this can be the source of the problem ? Maybe the new editor 1.42 use those instructions set ?

If it is the case, is there a way, without making a lot of work on it, to propose a java version of the new editor to keep compatibility with old system ?

Thank's


#5
Thank you froggy77 for your answer !

For my first post i used solarus on my pc at home which is much more recent, so no problem to make the editor run. The problem is with the pcs at my work.

I think those old pcs are also under sp3 and directx0.9c but i'm not sure, i will check this incoming week, if it is not the case it could be the origin of the problem.

The problem happens if you launch the editor's exe directlty or launch it with a shortcut to the project as I also usualy does. So I don't think the problem is due to a corrupted data project, but really the new editor exe thates crash on those old configuration, although the previous java version 1.3.1 of the editor worked well.

If i don't find a solution, could it be possible to publish a java version of the editor that seems more versatile that the new executable version ?
#6
Hello,

I'm using solarus on old pcs under windows XP and the new editor version 1.42 crashes systematicaly at load with the error :

"The application failed to initialize properly (0xc000001d)"

Untill now all the previous editor's version worked fine withount problem, even if the configuration of those old pcs are completely outdated (but the last windows update are done on it). I'm using those machines for education purpose in a school and have only those pc available for this task (there is no possibility to buy new one for the moment because of limited budget reason). So unfortunately i can't use the new editor with this pcs but only at home with a more decent machine.

I imagine the new editor is requiring more ressources and graphical functions than before, but in case of, do you think there is a way to get around this problem or can you precise what is the minimal configuration to use the new version 1.42 of Solarus (maybe with minimal directX version) ?

Thank's for your help
#7
Hello,

I'm trying the new editor 1.42 that is really nice and a big improvement to the previous one.

I believe there is a little bug with door item at least on my configuration. When you use contextmenu to change its direction (ie left to right), the door's icon is not updated immediatly. To make it change to the new direction you have chosen you have to go in its property pannel by double clicking on this door icon, where you can see that the new direction has really been changed but not visualy applied, and then make ok. This makes the door icon takes the good direction.
#8
Bugs & Feature requests / Re: Problem resolved
August 06, 2014, 07:02:55 PM
I didn't imagine it was possible to do that  :). The second code is effectively more clear for me.

Thank you, now i know 2 ways to load a module, but even if the load_file method is ugly as you say, i find it more simple to code (and understand) than the tricky method using "require".

Anyway even with this "require" method to load "play.lua", the timer still crash the same way. So my problem is not linked to the module's loading as i first believed  but to the timer when it is called by game:on_started.


Finally i think i have found from where comes the crash. I simply add a context to the timer. The doc says it is optional so i never used one so far, but with a context in the timer i have no more crash. I have choosen "game" even if i'm not sure this is the best choice in this case, but it works :


sol.timer.start(game, 1000, function() end)


So what happened is maybe that the context to which the timer was linked by default (as i don't gave one before) is cleared, or something like that, when the game restart and then the timer having no more context, goes to crash. It's why this crash occured only when the timer is put in the game:on_started() function and nowhere else.


I wonder if it's possible to rename the post : "crash with timer" or something like that, now that we know the problem has nothing to do with the "sol.main.load_file" as i first believed. It would be more clear don't you think ?
#9
I have made some more tests to include other part of zsdx that i didn't use for now on, like the dialog box which use "sol.main.load_file" to include its modules and it works fine. So the problem of my situation doesn't come specifically from the command "sol.main.load_file".

Also i have said in previous post that the crash occurs when using a timer or a print function, so i was not sure if the problem was coming only from the timer.

But i have now remenbered that the print function i used is a custom one, in which i have added some weeks before a timer just to erase the text printed after some seconds, because it was more easy for me when debuging. So i try to removed the timer in my custom print function and solarus don't crash.

So now i can be more precise : this is apparently the sol.timer.start (whatever callback function you put inside) that crash solarus when used in a module called this way :

in the main.lua

sol.main.load_file("play.lua")(game)


in the module play.lua

local game = ...

function game:on_started()
 
  sol.timer.start(1000, function() whateveryouwant end)
 
end 


This happens even if the timer is not directly called by game:on_started but by a another function that is called by game:on_started (even in another module).

but what is strange is that the crash happens only if the name of the function is game:on_started, if i use game:on_finished or game:whateverelse() it doesn't crash.

So it doesn't make much sens for me and i don't know if it is a bug, or if i'm doing something wrong.
#10
Thank you vlag for your help,

When you say that it will not work, are you speaking of the method using "sol.main.load_file" or using "require" ?

In ZSDX the module (play_game.lua) that contains the function "game:on_started" is loaded (in main.lua) using the "sol.main.load_file" method as i am trying to do without sucess.

I try to put a return false in the timer as you propose, but it still crash. But i don't think the problem is with the timer, because the crash can occured with other functions, it was just an example to show the problem. Anyway in my complete code the timer callback function is not empty (this serve to check if the rupee money display has changed).

If some day you have time, you can try to see if you can reproduce the crash by using the two files in attchaments (main.lua and play.lua) and put them in the data folder of the "sample_quest" in the zip file of solarus 1.2 engine.
#11
Thank you for your quick answer,

In fact I already used this trick because it is used all the time especially to pass "game" to some functions who need it and it works well :


-- in the module play :

local init = {}

   function init:create(game)   
       hud_initialize(game)   
   end   

return init

-- in main.lua :

init = require("play")
init:create(game)


But i'm not sure it will be sufficient in this case, because it is not the same kind of "arguments passing" we need and this is not a custom function. I have to add an event "on_started" to the "game" table that is already defined by the engine :


function game:on_started()

    hud_initialize(self)   

end   


This is the code that will be called each time the game start, so i can't call it "whatyouwant:on_started()" it has to be called "game:on_started()" or a variable name that will be replace by the table "game" when solarus will run, and i don't think "require" can do it.

I thought it was why in DX you use the other "load_file" function that allow to pass directly arguments (here it is the "game" table) to the module even to the name of the function, thanks to the first line you use "local game = ..." that receive the argument passed by "load_file" :


local game = ...

      function game:on_started()

      end


I think this is a different way of loading the files than "require", but unfortunately i can't manage to make sol.main.load_file works without crash.

Also i can't put simply this function in the main.lua as the table "game" will not be defined at this stage and the compilator is not happy. So this function has to be in a module.
#12
Hi,

I need some help because i am fighting with an ununderstandable problem that systematically crash solarus.

I was trying to build the elements of the hud (rupee, heart...) to understand how to do it and without any problem so far. But doing my test, i realized that when the game restart because the hero died, the hud didn't come up again.

So i look in the script of solarus DX and understood that i have to put something in a  "game:on_started" function that is called each time the game restart after the death of the hero, that will reinitialize the hud.

So i try to do so by copying the way it is done in DX and there the problem begins.

So far to include module files in the main.lua file (for example for the hud.lua) i was just using "require(filename)" that works well. But i have seen that to declare the "game:on_started" function, another way of calling a module is used with "load_file" which is an adapted version of lua "loadfile" command for solarus. So i search a lua help to try to understand this command and find this :


-- just load the module without runing it
sol.main.load_file(filename)
-- load the module and run
sol.main.load_file(filename)(some arguments)


if i have well understood the avantage of "require" is that it loads the modules only once (so preserves memory), but it doesn't seems to be able to send arguments to module's function. To be sure I try the following :


require(filename)(some arguments)


but it doesn't pass the arguments. So I then try to use the "load_file" instead as shown in the DX's script and do exactly as it (at least i think so). And then solarus begins to crash all the time.

As i have put some code inside "game:on_started" i try to undertand what part was causing the crash by removing things little by little. But it was complicated because the crash occured or not depending if i add or remove some instructions somewhere in this module or in another one called by "game:on_started", even sometimes on very simple command like "print". So it wasn't easy to localize which part was the problem because it doesn't crash with any commmand but only with some of them.

For example i have seen that i have timer called in one of my module, and i discover that if i comment it, then there's no crash (but i need this timer).

Finally i make a copy of the project and take everything out (all modules and even clean the main). Now i have a mini project with just 2 files: main.lua and a module called play.lua in the data folder. And it continue to crah my solarus (version 1.2 or 1.21).

To be sure there was not a little part of my code hidden somewhere (or in the map definition for example) that gives instability to the program, i have took back the "simple_quest" example proposed in solarus 1.2 zip file you can download on solarus site and that you try at the begining to understand the basics of solarus.

It is just composed of one map inside a house where you almost can't do anything. It was the first example i begun with, and i knew it works well. So i just took this data folder and just change the "main.lua" by mine and add my problematic module "play.lua" and then... it crash solarus. I really didn't changed anything else than this 2 files. Here they are :


-- main.lua
function sol.main:on_started()

    game = sol.game.load("save1.dat")
    game:set_max_life(12)

    sol.main.load_file("play")(game)

    game:start()

end



-- play.lua

local game = ...

function game:on_started()

    -- this simple timer that does nothing make solarus crash
    sol.timer.start(100, function()  end)
     
end


For me, this very simple code crash solarus with nothing log in the error.txt file, but if i comment the call to "sol.main.load_file" the quest start on without problem.

(In my real code the game create process and game:start() are not in the main.lua but in a game_manager.lua, i just put it there to simplify at the maximum).

So probably i'm not using the command sol.main.load_file("play")(game) like it is neccessary because in DX it works without problem. But i don't see what i do wrong by comparing with the use of it in DX.

I must precise that the timer function i use in method "game:on_started" is just an example. It is one of the function that i have localized to cause the crash in some of my modules called by "game:on_started".

But in my code, even a simple "print" function" make a crash (it depends where it is put). This is not the case in this simple version because i have removed all the other modules that "game:on_started" is supposed to call when the game restart.

So i don't think the problem comes from the timer itself as the problem occurs with other functions. If i put this same timer command in the "main.lua" it runs without problem, it is only inside the "play.lua" file that it makes crash. In my real code, the timer is set in another module called by "game:on_started" so that the crash wasn't localized directly in the play module although the problem seems to come from there.

In "main.lua" i also try another variant used in DX to call load_file, but it crash the same :


-- main.lua
function sol.main:on_started()

    game = sol.game.load("save1.dat")
    game:set_max_life(12)

    local mytest = sol.main.load_file("play")
    mytest(game)

    game:start()

end


I wish to use "require" instead because it never make crash solarus, but apparently it is not possible because it can't parse the argument "game" to the module "game:on_started", although it really needs it.

So could you please help me as i don't know what to do more.

If you don't see a big big stupid error of beginer from my code that will be evident to your expert eyes, could you then try to do like me by taking your "simple_quest" given with the solarus 1.2 engine and put those two files (see attachments) in the data folder to see what happens and if it's normal.

Thanks a lot
#13
Hi,

Thank you very much for all those enormous precisions, it is perfectly clear now on all that points and i have well understood what the menu functions are really doing and why to use them. I really appreciate you take so much time to explain this and hope it can help also one day some other new comers.

Thank you again.
#14
Hi,

I'm trying to understand the lua code of solarus by reading the differents scripts of zelda solarus dx and i am stucked by some special trick, especially some specific to solarus. So could you please explain me some of them (apologize for the length of this post and if some of my questions are very naïve as i'm new to solarus and lua).

1) The hud code :

For each element of the hud (the rupee, the heart...) it seems you define a lua pseudo class of this element (by using the metatable) in this code that is always at the begining of the lua file (example taken from the rupee.lua in hud folder):


local rupees = {}

function rupees:new(game)

  local object = {}
  setmetatable(object, self)
  self.__index = self
  object:initialize(game)
  return object

end


and then in the hud.lua code you call this constructor to build an instance of this class for all the object of the hud, for example:


local rupees_builder = require("hud/rupees")
local menu = ruppy_builder:new(self)


I have understood what this code does, but what i don't understand is why it is necessary to create such a pseudo class as i don't think you use them elsewhere (i'm not sure of that). To my little knowledge, when you create a class, you have in mind to be able to create many instance of that class to use those objects in differents situation. But here, if i understand well, the rupee class is used only once (for the hud).

So is there a special reason why you use a more complex structure in the constitution of the hud. Because exactly the same code without the method "rupees:new" (just using the rupee table as it is), will work the same. Or the class structure is more adapted for the hud, for any reason. Otherwise maybe is it just because you plan to use this class for something else in a future version of solarus ?

2) The use of menu:

The use of the menus are not very clear to me. In the doc you explain that the utility of a menu is to allow to add some callback functions to any table that already exists (at least this is what i have understood). But is the menu itself an object created automaticaly by the engine when you call some of its function (start, stop...) and that includes the table that called the menu or does it just add some functions to the table that has called him ?

For example, still with the hud example, after having create the hud's element, you allow their showing by runing this function where you use the menu function (taken from hud.lua) :


function game:set_hud_enabled(hud_enabled)
    ...
    loop on menu...
    ...
         sol.menu.start(self, menu)
    ...
    end
end


where menu is one hud element (like the rupee) created before and placed in the hud table.

At the begining i didn't understood why the call to one of the draw function wasn't sufficient to show an item (like the rupee icon), beacause you have also to use a menu.start function for it.

For the example of the rupee, to show the icon of the rupee (near the number of money of the hero at bottom left) you use something like :


local rupee_icon_img = sol.surface.create("hud/rupee_icon.png")
rupee_icon_img:draw_region(x0, y0, width, length, dst_surface, x, y)


the first line create an image object of the icon called a "surface" in solarus environment and the second one is called to draw it on the screen. But when it is called alone nothing happens apparently. To make it works you have to put the "draw_region" in a callback function of a menu:


sol.menu.start(game,rupee_menu)

-- and somewhere create a callback function:

function rupee_menu:on_draw(dst_surface)

   rupee_icon_img:draw_region(x0, y0, width, length, dst_surface, x, y)
   
end   

   
then the image of the rupee is well displayed.

So please correct me if i'm wrong, because what i am understanding from this procedure is maybe completely idiot.

My understanding is :

In fact, unlike what i was first thinking, the "draw_region" function  display only one time the image it have to show. But as the screen is refreshed at a certain frequency by solarus engine, if you display only once, you don't really see it, as the screen is then immediatlely again redrawn and if the draw function is not called again the rupee disappears. To be sure you see it all the time, you have to called this draw function every cycle of redrawn of the screen.

So this is where the role of the menu is coming. The menu add a callback function to the rupee_menu table and each time the engine start a redraw of the screen, if it sees that a table has a callback function "on_draw" (added to the table by the menu or include in a table "menu" ?) then it will run this callback function to draw what is asked in this function.

Does it works like this or i'm completely misleading on the use of menus ?

3) Entity code:

Last thing, completely different subject, i wish to ask you if it is possible to make a lua code for the entity that appears on the map (teleporter, crystal, switch...) to customize their behavior.

For the enemy, item or custom_entity, when you create a new item of them in the quest editor, it automaticaly create a lua file that goes in their respective folder. But for the entity, it seems that when you create a new one, you can only give them a name and choose some specific properties, but you can't give their special behavior in a lua files as the other entities. This is maybe why they don't have their own folder in the quest editor like the others elements, but are placed inside the folder of the map (on the treeview at the left).

In the french tutorial videos I have seen (many thanks for them, they are really more than helpful to understand solarus), when you need to add a new behavior to an entities, you do it directly in the lua file of the map, although with other kind of sprite (enemy etc...) they have their own lua script. I works well also, but i was thinking that with large project it can become difficult to read the lua map file if we put a lot of scripts for all the differents entities added to the map. It could be more clear if they could have also their own lua files.

So even if apparently it is not proposed by the quest editor, is there a way to add some behavior to those kind of entities in an independant lua file, or is it a choice not to proposed this possibility ?

Thanks you very much for your help
#15
Development / Notepad++ autocompletion for Solarus
August 01, 2014, 05:15:39 PM
Hi,

I didn't find around a notepad++ language file for Solarus (maybe it already exists somewhere ?) to have autocompletion. So i made one, as i think it can help at least the beginers to know easily the existing functions or methods, or just verify their parameters and of course to script more quickly long function's name. It is made from the solarus 1.2 doc website, so it should be uptodate so far (http://www.solarus-games.org/doc/latest/index.html).

Some people don't like much this kind of help, but it may be useful to some others, so here it is. It's the first one i make, so please excuse me if it is not made properly as it should or if it is incomplete. Also there is certainly some errors in it as it is difficult to test them all, so if you find errors by using it please don't hesitate to tell.

For those who don't know, you can activate autocompletion in notepad++ in the preferences (see picture 3).

As far i have understood, the file language must have the same name that the extension for which this language file should be applied. So the file is named "lua.xml" and has to be put in the plugins\APIs folder of notepad++. Normaly it is automatically recognized by notepad++ when you open a lua files as those of Solarus scripts.

Remark: It means that if you already have a more general lua.xml files applying to general lua language it wil replace it. If you then use lua files back for another environement that Solarus, you will have to change it again as lua is widely used for a lot of different applications.


Limitation:

1) First I have removed the begining "sol." extension on every functions and methods otherwise it gives too more results each time you begin with sol., so i thought it was not much effective.

2) In the case of showing the parameters of the functions (see picture 2), there is apparently a limitation in Scintilla/notepad++ autocompletion to recognize function's name separated with dot like "sol.main.load_settings". So only "load_settings" will be recognized.

To avoid this problem i have add those two versions (with and without the part with dot: "main.sol."). So the autocompletion mechanism propose the complete function "sol.main.load_settings" that allow to choose it without writing it all, and then after writing the "(" it show also the different parameters accesible for this function.

But this doesn't work when the function exists under different objects with different parameters:

For example timer.start should show :
sol.timer.start([context], delay, callback)

but will show:
sol.timer.start(context, menu, [on_top])

because only the end "start" function is recognized and taken from "sol.menu.start(context, menu, [on_top])" that comes first in the file, as again the begining "sol.main.timer." is not recognized.

I don't know if there is a solution to this problem, but it affects only a few functions, so it shouldn't be a big deal.

Thanks.