LUA or PyGame

I was wondering, me and my buds wanna start making a game and we wondering which language (LUA or Pygame) we should use for that. Any recommendations or information about these 2?

>>26

no there are no lists unfortunately. People typically implement lists using tables like structs,


a = {}
a = {item='data1', next=a}
a = {item='data2', next=a}

If you wanted more efficiency, you could use try using c extensions to create a simple list for lua, but I'm not sure how you could get your C list to register its references with lua's garbage collector. It might be possible, but I haven't looked into it yet.

>>30

nevermind, according to these people, you can't

http://stackoverflow.com/questions/3034247/lua-userdata-gc

It doesn't look like you can refer to lua objects from your c code. This seems unnecessarily limited to me though. It's not like it would be difficult to register some userdata with a custom marking function written in c, that could get called by the garbage collector to mark the userdata object's references. also my list was wrong. First line should have been a = nil

>>31
The point of lua is to be a simple, lightweight scripting language. If you want something more robust, there are options. Every scheme distribution I can think of is made to do this sort of thing. Of course, using them becomes that much more complicated, which defeats the whole point of selecting a lightweight, simple scripting language in the first place.

Enjoy.

Lua is really fun to use.

>>33
oh you never had to write for awesome window manager

(actualy it's it's awful standart library, BUT NEVERTHELESS)

>>32
Lisp is shit.

>>31
To keep a reference to a lua object use
http://www.lua.org/manual/5.1/manual.html#luaL_ref
to get an unique key for it, and insert it into a table.

When it's time to release the reference, use luaL_ref again
but this time remove from the table.

Requiring you to do it in this kind of indirect way instead of having an equivalent to Python's Py_INCREF() and ability to call custom destructors for values of types other than table and userdata is a major Lua weakness, specially when version 5.2rc1 goes live with the new continuation based API for yielding out of CFunctions.

If it ain't Lisp, it's crap.

Luajit. http://luajit.org/

Python is fucking shit.

>>36
Reference counting is a major python weakness.

>>39
What abount absence of uniform syntax, leading to inability to extend it though macros?

>>1
'>LUA

>>30
nigga are you kidding me


herp = {">>30-san", "is", "a", "fgt"}
for _, val in pairs(herp) do
    print(val)
end

>>33
one has to know that the Lua defs refuse to add a sane "class" syntax to Lua, despite the fact that Lua supports class-like statements just fine. it seriously boggles the mind

apart from that, Lua is meant to be embedded, hence why it's so small. if it were meant to be used like Python, it would be hyperbloated with at least 2340235340508345895736958739056356346 billion standard libraries (each reading XML files in different ways, because reading XML is what the cool kids to these days!).

so cram it, haterz

www.love2d.org

>>42
You could say the same thing about C structs. Make Lua++ if you are so in love with syntax.

>>42
one has to know that the Lua defs refuse to add a sane "class" syntax to Lua

class "Anus" ("Haxable")
    :init(function (self) print "hax my anus" end)
    :destroy(function (self) print(self.haxed and "haxed" or "not haxed") end)
    :method "hax" (function (self) self.haxed = true end)
    :method "shit" (function (self) collectgarbage() end)
Terrible!

Forget about Lua and PyGame.  Go with SFML 2.0 with C++.  It's very easy to use, and your binaries will work on Windows, Mac & Linux.

>>32

Adding a custom destructor for userdata is a feature, that if you didn't need, you could simply not use it. You could use a language without ever knowing about such a feature, and then things would be just as simple. It would require maybe a few additional lines of code to the garbage collector. There would be no additional run time cost, as userdata with a custom collection function could be marked with a new type tag that would get switched off of. You could implement state of the art data structures in C, and use them to store lua objects. This would be nice, for people who wanted to achieve the satisfaction of using a list that is really as fast as possible. With lua as it is, there is no way to bypass at least some kind of table access when traversing a list. This table access could be optimized though. Like if the jit or whatever could detect that you always use constant values keys to index into a table, it could just treat that as a compact structure. If you could eventually get the same performance as C, then this wouldn't be very necessary.

This would have a big disadvantage though, in that it would need to completely expose how the gc worked. If the gc implementation was to change, then all the c extensions with collector call backs would need to be rewritten. Or if different implementations of lua used different collection methods, it wouldn't work at all. There is also the issue of buggy c code doing weird stuff with lua, like incrementing a reference count too many times, or decrementing something too many times. This could be very difficult to trace.

Lua is a shitty language and I really don't understand why Mike Paul spent the time to make a great JIT for it. It should have been SchemeJIT.

>>45

dat currying. It takes creativity to come up with something like that.

here's what I do:

-- inside of anus.lua

local Haxable = require'Haxable'
local oo = require'oo'

local Anus = {}

function Anus:init()
  print "hax my anus"
end

-- I don't have destructors..    :destroy(function (self) print(self.haxed and "haxed" or "not haxed") end)

function Anus:hax()
  self.haxed = true
end

function Anus:shit()
  collectgarbage()
end

oo.class(Anus, {Haxable})

return Anus

class "Anus" ("Haxable")
    :init(function (self) print "hax my anus" end)
    :destroy(function (self) print(self.haxed and "haxed" or "not haxed") end)
    :method "hax" (function (self) self.haxed = true end)
    :method "shit" (function (self) collectgarbage() end)

>>48
Lisp is shit.

Lua with LÖVE is just as viable as Python with PyGame.

>>45
don't make me punch you

>>49
this is fucking awful and you should feel awful for writing it

>>52
punch my anus

>>52
problem?

>>39
How so? Ref counting is fast, memory gets freed right after it's not needed. And it has a backup cyclic detection GC if you are dumb enough to make cycles.

>>55
Ref counting is fast, memory gets freed right after it's not needed.
I'm a die-hard C advocate but I must say that is absurd. If you're going to have automatic memory managment for everything don't use a half-baked solution that will botch the cache up even more than a real GC. Not to mention Python is shit.

>>56
How do you explain the super speed of Vala (almost identical to C speed) and using auto_ptr for everything in C++?

>>52
fuck you faggot, I'll POOP in your shitty scheme if I want to

>>57

I think that what >>56 wanted to say is that there are some things for which you don't need automatic memory management, and it would be a waste. OTOH, if you do want automatic memory management for everything, a proper GC is better than solutions which are intended exactly for the first, more selective, case.

>>55
Ref counting is fast
memory gets freed right after it's not needed.
Why not free it when you have nothing else to do, instead of rightnowrightnowrightnow?

>>59
Let's forget about C++ for a second and simply concentrate on Vala. I'm fairly certain Vala uses ref'd gc for everything, and all objects are allocated on the heap- yet the benchmarks[1] show it's pretty much on-par with C and C++ in terms of speed.

Just skimming a few of the benchmarks shows they are using objects and writing pretty much idiomatic Vala code, so I'm not sure what the problem with ref counting actually is.

Are saying is with a real GC scheme, Vala would be even faster?

[1] http://code.google.com/p/vala-benchmarks/wiki/BenchResults

>>61
No. Maybe >>56 would say that, but I wouldn't. I believe that reference counting schemes, despite inherent problems they may have, are fairly good, simple schemes.

The typical problem involving refcounting is related to circular references between objects. I'm not sure whether this occur with C++-based shared pointers, though, because of the presence of destructors.

>>62
You know what's simple? Using a garbage-collected language. If you're going to roll your own shit you have already given up simple.