Been a while since I posted, and I'm not sure if my post belongs here, but for the last 6 months I've been learning lua and created a pure lua simulation of running a restaurant. Tis all numerical and the only user intervention is clamped to changing the data tables by hand before the simulation runs.
Anyone remember Pizza Tycoon or Restaurant empire? In about 300+ years, I expect my simulation to be very similar, except I'm focusing on re-playability, financial reality, and absolute micro-management. Note I didn't use the word 'game' at all.
Having said that, I'm trying (as a newbie) to roll my simulation into a game-like form using the love2d/lua combo. Unfortunately, I'm still having a tough time wrapping my head around some of the love2d concepts. To keep things brief, I'll just ask a few stupid questions:
1 - What are the rules when using someone elses code? Would giving credit where credit is due be good enough? I mention this cuz "randomlua.lua" is the CORE pseudo-random number generator in my sim. <-- Mostly cuz I've read RND generation within lua isn't exactly stable across platforms.
2 - Is there no way to snag/copy a piece of the on-screen data (Sorta like a screen snapshot) but within a defined rectangle? Leads into question 3.
3 - What is the preferred way to create vertical scrolling text? I want a small box on my display to constantly push data (String) upward on a regular basis. The first thought I had was to snag/copy a section of the screnn, and just copy it back minus about 12 pixels, then print out the new data. Love2d seemingly can't do that? I ended up having to create a table, shove the strings there, and use table.remove/table.insert to control what was drawn on the screen every frame. This seems very weird to me. Surely, there is a way to simulate what a simple console device does in love2d? Right?
4 - Does 'screenshot = love.graphics.newScreenshot( )' even work? For some reason, I'm not able to see any results. And yes, I followed the wiki page instructions to make raw data into a drawable image. No errors and no visual results. Have I missed something?
Any suggestions appreciated...
Thanks
Newbie questions?
- Hexenhammer
- Party member
- Posts: 175
- Joined: Sun Feb 17, 2013 8:19 am
Re: Newbie questions?
That depends on the license of the code in question. Source code is subject to copyright law just like literature. Usually the source code itself contains a license statement right at the top of the file. If not, then the license is included in the source package. If there is no license to be found, you have a problem, because you cannot legally use the code.. Of course, you could simply ignore the law based on the probably correct assumption that the author intended his or her source code to be freely useable by everyone.Grubby wrote: 1 - What are the rules when using someone elses code? Would giving credit where credit is due be good enough?
>I mention this cuz "randomlua.lua" is the CORE pseudo-random number generator in my sim. <-- Mostly cuz I've read RND generation within lua isn't exactly stable across platforms.
The soon to be released next version of LÖVE (0.9.0) will ship with a better PRNG which should return identical results on all platforms.
Re: Newbie questions?
Thanks for the replies. An Oops on my part was that I was reading a rather old version of the Downloadable wiki. It never mentioned 'screenshot' worked only for 0.9.0. And yup, no error from love2d when using the screenshot function with the windows build of 0.8.0. As for using someone else's code, I don't like the idea, but there ARE some things so basic to computers (usable GUI) it just doesn't make sense to re-invent the wheel. Especially if it's just the plan for the wheel. I can carve the actual wheel myself.
Anyone mind if I ask a few more dumb questions?![Smile :)](./images/smilies/ms-smile.png)
Not sure why I'm asking this, but I thought I read somewhere that improper declaration of variables (style) can impact memory usage within Lua? Any truth to that? If so, any place I can read up on optimizing lua code or maybe some lessons on proper style? Again, the notion of programming style as an issue seems weird to me. Back in my C days, it really only mattered if I expected someone else to read and understand the code. Tab key? Whats that?
Currently, my love.load() function is getting way too huge to manage. Now that I'm incorporating some of my simulations data tables, I'm having a tough time trying to alter/test the love2d specific things I want. Gots to be a better way. Can I use 'require' to set up just my simulation data tables? Or would it be worth the time this early to just code some kind of 'table' loading mechanism from a file? As a dumb idea for testing, I actually have all my recipe and ingredient tables stored in an OpenOffice spreadsheet. Oh yes, I mean the actual lua version of the tables so that I can change and export them back into love.load() with little need for formatting. See, I told you I was daft. Does any of this stuff even need to be in love.load()? So what exactly would be the best way to handle this?. I'd rather not code some kind of file system thingy just yet.
Sounds? I'm planning on that, but far into the future. Doesn't mean I can't start coding something now. At least to test and play around with love2d. I envision no more then 16 to 24 possible sounds. Some of these would be small to really small for GUI use like menus or command buttons. But some of these will be used to create ambience like a crowded restaurant. <- This last thing I expect to loop continuously and possibly change in volume as the number of customers in the restaurant increases. Now I know my question is opinion based or perhaps common sense related, but how big would/should I go for sound data I want as static? How large would a sound bit need to be for the streaming option to make more sense? Also, where exactly in the love2d wiki does it point out how to constantly loop a sound over and over?
Licensing? Yah, Right... Lets just assume that within the next year or so my simulation reaches distributable maturity. I would want it to be open-source, usable by most, forked by most. I DO NOT want it used as a base for a commercial endeavour. I would NOT want it used by greedy commercial entities that will go unnamed. And above all, no fusking on-line activation [had to throw that in there
] or any sort of Internet related code would be allowed to co-exist with the code base. Anything out there that covers that?
Any suggestions or comments appreciated.
Thanks,
Anyone mind if I ask a few more dumb questions?
![Smile :)](./images/smilies/ms-smile.png)
Not sure why I'm asking this, but I thought I read somewhere that improper declaration of variables (style) can impact memory usage within Lua? Any truth to that? If so, any place I can read up on optimizing lua code or maybe some lessons on proper style? Again, the notion of programming style as an issue seems weird to me. Back in my C days, it really only mattered if I expected someone else to read and understand the code. Tab key? Whats that?
Currently, my love.load() function is getting way too huge to manage. Now that I'm incorporating some of my simulations data tables, I'm having a tough time trying to alter/test the love2d specific things I want. Gots to be a better way. Can I use 'require' to set up just my simulation data tables? Or would it be worth the time this early to just code some kind of 'table' loading mechanism from a file? As a dumb idea for testing, I actually have all my recipe and ingredient tables stored in an OpenOffice spreadsheet. Oh yes, I mean the actual lua version of the tables so that I can change and export them back into love.load() with little need for formatting. See, I told you I was daft. Does any of this stuff even need to be in love.load()? So what exactly would be the best way to handle this?. I'd rather not code some kind of file system thingy just yet.
Sounds? I'm planning on that, but far into the future. Doesn't mean I can't start coding something now. At least to test and play around with love2d. I envision no more then 16 to 24 possible sounds. Some of these would be small to really small for GUI use like menus or command buttons. But some of these will be used to create ambience like a crowded restaurant. <- This last thing I expect to loop continuously and possibly change in volume as the number of customers in the restaurant increases. Now I know my question is opinion based or perhaps common sense related, but how big would/should I go for sound data I want as static? How large would a sound bit need to be for the streaming option to make more sense? Also, where exactly in the love2d wiki does it point out how to constantly loop a sound over and over?
Licensing? Yah, Right... Lets just assume that within the next year or so my simulation reaches distributable maturity. I would want it to be open-source, usable by most, forked by most. I DO NOT want it used as a base for a commercial endeavour. I would NOT want it used by greedy commercial entities that will go unnamed. And above all, no fusking on-line activation [had to throw that in there
![Wink ;)](./images/smilies/ms-wink.png)
Any suggestions or comments appreciated.
Thanks,
- slime
- Solid Snayke
- Posts: 3153
- Joined: Mon Aug 23, 2010 6:45 am
- Location: Nova Scotia, Canada
- Contact:
Re: Newbie questions?
It's available in earlier versions. 0.9.0 changed its functionality slightly to default to being always opaque, and added an optional parameter to toggle that.bekey wrote: As for the [wiki]love.graphics.newScreenshot[/wiki], not having 0.9 would probably cause an error, but just to make sure I'll say it: It's only available in 0.9 which you probably have anyway.
Re: Newbie questions?
If you're using luajit OR LÖVE 0.9 (which by default will use luajit) OR LÖVE 0.8 compiled with luajit, RNG WILL be stable.Grubby wrote: 1 - What are the rules when using someone elses code? Would giving credit where credit is due be good enough? I mention this cuz "randomlua.lua" is the CORE pseudo-random number generator in my sim. <-- Mostly cuz I've read RND generation within lua isn't exactly stable across platforms.
That would be reaaaly slow. (Writing == fast, reading == slow). You could ofc do that on canvas, but what bekey has written is easier, and probably more sensible way to do it (i.e. think if you'd like to change font size dynamically).Grubby wrote: 2 - Is there no way to snag/copy a piece of the on-screen data (Sorta like a screen snapshot) but within a defined rectangle? Leads into question 3.
"We must have perseverance and above all confidence in ourselves. We must believe that we are gifted for something, and that this thing, at whatever cost, must be attained." - Marie Skłodowska-Curie
- Robin
- The Omniscient
- Posts: 6506
- Joined: Fri Feb 20, 2009 4:29 pm
- Location: The Netherlands
- Contact:
Re: Newbie questions?
What? I've never heard of that. Maybe what you're referring to is the fact that locals are faster to access than globals, but that never matters in practice.Grubby wrote:Not sure why I'm asking this, but I thought I read somewhere that improper declaration of variables (style) can impact memory usage within Lua? Any truth to that? If so, any place I can read up on optimizing lua code or maybe some lessons on proper style? Again, the notion of programming style as an issue seems weird to me. Back in my C days, it really only mattered if I expected someone else to read and understand the code. Tab key? Whats that?
Help us help you: attach a .love.
Re: Newbie questions?
Nevertheless you do gain some signifiant time when you declare all your variables, even internal or user functions, as local from the start. It's because local variables are accessed directly, unlike global variables which are stored in a table.locals are faster to access than globals, but that never matters in practice
So, in Löve, don't put all your variables in the 'love.load()' function or declare them rather as local at the top of your script, apart from any function.
Last edited by Bereb on Tue Dec 10, 2013 9:11 am, edited 1 time in total.
Re: Newbie questions?
It could refer to declaring them as globals in functions and then never using them again; they'll linger in memory for no good reason, chewing up memory. But again, that's little more than making sure you declare them as local.Robin wrote:What? I've never heard of that. Maybe what you're referring to is the fact that locals are faster to access than globals, but that never matters in practice.Grubby wrote:Not sure why I'm asking this, but I thought I read somewhere that improper declaration of variables (style) can impact memory usage within Lua? Any truth to that? If so, any place I can read up on optimizing lua code or maybe some lessons on proper style? Again, the notion of programming style as an issue seems weird to me. Back in my C days, it really only mattered if I expected someone else to read and understand the code. Tab key? Whats that?
- Hexenhammer
- Party member
- Posts: 175
- Joined: Sun Feb 17, 2013 8:19 am
Re: Newbie questions?
Lua variables are global by default, limit their life time by making them local. Intuitively the keyword for that is "local"Grubby wrote: Not sure why I'm asking this, but I thought I read somewhere that improper declaration of variables (style) can impact memory usage within Lua?
![Glee ^^](./images/smilies/ms-glee.png)
Code: Select all
fatassGlobal = "I am"
local slimLocal = "I am"
Optimal coding style depends on the implementation used. Vanilla Lua and LuaJIT demand different coding styles for optimal performance. If you care about performance LuaJIT is the only option though. Optimizing for LuaJIT is fortunately easier than optimizing for Lua because LuaJIT does all the trivial stuff itself. Just use traditional Lua module style i.e. everything is stuffed into a local table, that gives LuaJIT the locality it needs. Note that LuaJIT's author stresses the importance of making performance-critical things local. Not just because it cuts a dereference but because it allows LuaJIT to make more assumptions. Note that you do not want too many local variables being live at once though, that degrades LuaJIT's performance. I.e. good style for LuaJIT:any place I can read up on optimizing lua code
Code: Select all
local MyModule = {}
MyModule.myVariable = 23 -- module variable
function MyModule.Foo(x)
local fooStuff -- variable local to function
...
end
function MyModule.Bar(x)
return MyModule.Foo(x) - MyModule.myVariable
end
return MyModule
Code: Select all
local myVariable = 23 -- module variable
local function Foo(x)
local fooStuff -- variable local to function
...
end
local function Bar(x)
return Foo(x) - myVariable
end
return { Foo = Foo, Bar = Bar }
![Wink ;)](./images/smilies/ms-wink.png)
Read the book of Lua's primary architect i.e. "Programming in Lua" by Roberto Ierusalimschy and follow that style. That is the closest thing to "proper" I can think of. Personally, I never cared much about being "proper"or maybe some lessons on proper style?
![Razz :P](./images/smilies/ms-razz.png)
Only thing I would put in love.load() would be a call to "Game.Init()". Game.Init() being the function which initializes the game by initializing all its subsystems which require initialization. E.gCurrently, my love.load() function is getting way too huge to manage.
Code: Select all
-- main.lua
function love.load()
Game.Init()
end
Code: Select all
-- Game.lua
function Game.Init()
MapGenerator.Init()
Actors.Init()
Orgasmator.Init()
end
Why do you keep the tables in a spreadsheet? Export them to Lua once and then work with the Lua tables. If you need to keep the values in a spreadsheet for some reason you have no alternative to writing a loader. Not familiar with OO.org but usually all spreadsheet apps can export CSV and you can write a CSV -> Lua table loader in a few lines of code.I actually have all my recipe and ingredient tables stored in an OpenOffice spreadsheet. Oh yes, I mean the actual lua version of the tables so that I can change and export them back into love.load() with little need for formatting. See, I told you I was daft. Does any of this stuff even need to be in love.load()? So what exactly would be the best way to handle this?. I'd rather not code some kind of file system thingy just yet.
Oh, and you do not need to code a file system thingy. LÖVE comes with its own file system which you should use if you want to stay compatible.
The GPL will keep commercial interests away from your game.Licensing? Yah, Right... Lets just assume that within the next year or so my simulation reaches distributable maturity. I would want it to be open-source, usable by most, forked by most. I DO NOT want it used as a base for a commercial endeavour. I would NOT want it used by greedy commercial entities that will go unnamed. And above all, no fusking on-line activation [had to throw that in there] or any sort of Internet related code would be allowed to co-exist with the code base. Anything out there that covers that?
Who is online
Users browsing this forum: Ahrefs [Bot] and 0 guests