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?

>>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.