LÖVE

AXavierB wrote:Like I said, I'm completely uneducated when it comes to programming, but isn't it possible to use a separate graphics engine if the main game engine isn't powerful enough?

With other technologies, yes. But LÖVE isn't built that way.

Robin wrote:

AXavierB wrote:Like I said, I'm completely uneducated when it comes to programming, but isn't it possible to use a separate graphics engine if the main game engine isn't powerful enough?

With other technologies, yes. But LÖVE isn't built that way.

For "uneducated" there is no other simple way in Love2d. For advanced programmers, there is option to use GLSL using upcoming version 0.8 to make some effects (programming GPU instead of CPU). Look here for examples: viewtopic.php?f=4&t=3733&hilit=glsl

But that's not a separate graphics engine, it's still LÖVE.

Löve is perfectly capable of drawing thousands of image calls every frame without slowdown. It's all about what you need to draw and how optimized your engine is. If it's a scroller, you obviously only draw what's on screen. In games like Braid and LIMBO, the maps are created from large images all rotated and placed on the screen rather than tiles. So these games actually draw LESS (If we don't count all the particle effects in Braid) in their base map drawing than a game that needs to draw 300+ tiles every frame.

It all comes down to the backend of the game. The processing of the world. The drawing is fast enough, you just need to make sure you're not doing too much processing. i.e. if an enemy is far enough off screen, don't process it's AI. If you code it well enough, don't actually create the enemy until he is right about to enter the screen. And destroy it if it's not needed anymore. Break levels into chunks and only process chunks currently within the screen area. In DOOM, levels were broken up into sections. And only sections on screen within the view of the player would be processed, up to 255 in a line. This was smart because you could have huge levels and as long as the player couldn't see way too much from any given area, it would run fine. Games like Braid, LIMBO and Aquaria use the same "large image placed on the map" method over the limiting tile method. I guess the bonus is that in Braid, levels were small enough that not too much is needed to be recorded. Maybe a handful of enemies, and platforms and the player.

Here's some videos:

Jonathan Blow talking about Braid from its first prototype to the final version. Notice how the original game used tiles.
http://www.youtube.com/watch?v=gwsi7TEQxKc

The making of LIMBO:
http://www.youtube.com/watch?v=qK5rbZjwEl0

I used to have a video of Aquaria showing how they make levels using large shapes, but since the game has an editor, you could probably see this for yourself.

Jasoco wrote:And then the time manipulation which requires you to record the location of every moving object in a level every frame with a constant framerate. I experimented with recording and the longer you record the more memory used up by the table.

Take some advice from FPS networking protocols (such as the oft-cited Counter-Strike Source networking model): Don't record every position every frame, rather, only record the control state changes. Then you can simulate every frame in-between, even at variable frame rates. Don't store "x=1, x=1, x=1, x=2, x=3, x=4, x=5, x=6, x=7, x=8", record "frame1=0, frame3=2" (assuming 0 means "no direction" and 2 means "right" in your game). Huge, huge data-saver.

Well, you also need to occasionally record positions to account for lag. Say it records a Forward movement, and then 3 seconds later sends a Stop Forward. But on the other machine, it's slow, so the player ends up moving forward, but lags and moves longer than 3 seconds, ends up further than he actually is on the other end, but is in the right place on the first side. You'll want to send out positions of objects every few seconds or so to compensate and "correct" object locations. I believe this is also how CS works. As well as other games.

How did DOOM work back then?

Networking is a very large topic, with lots of tricks up its sleeve to account for ping and packetloss. This is how Valve games do it: https://developer.valvesoftware.com/wik ... Networking