smooth scrolling 2D game: possible?

[scrolly]

Hello!
Would LOVE be appropriate (fast enough) for writing a high resolution (1920x1080), smooth scrolling 2D game?

By scrolling, I am talking about Castlevania / Super Metriod / Mario style, where the game is always scrolling in some direction as the player moves. Being able to do Parallax scrolling would be even better.

I tried doing something like this with Python + Pyglet a few years ago, and it seemed very choppy and jittery. Not smooth at all. Someone on their fourms had the same issue, he solved it by writing a C extension, but that's way over my head.

When I look for examples of side scrolling games written in Love, Python, etc, they always seem to be written for a 800x600 window or something small, and are never "video game smooth" scrolling.

Can anyone point me to examples if they exist? Or is LOVE too high-level and I'm doomed to having to learn OpenGL & C++?

Thanks!

[micha]

Yes, this is possible in LÖVE.

LÖVE uses OpenGL, which makes the graphics fast. Programming in C++ would only make the game logic faster, but not the graphics.

[scrolly]

Yes, this is possible in LÖVE.

LÖVE uses OpenGL, which makes the graphics fast. Programming in C++ would only make the game logic faster, but not the graphics.

Pyglet uses OpenGL too, and it could not do smooth scrolling. It would jitter randomly.

I didn't fully understand the explanation as to why this was - one reason was Pyglet used "ctypes" which is I guess a slower way to interface with OpenGL, the other reason was that the main loop is Python, which is going to be too slow for doing 1000's of OpenGL calls per second.

I would think LUA would also be a slow, but I've read the latest LOVE uses LuaJIT, so maybe not anymore?

[Wojak]

LÖVE has ways to limit the number of OpenGL calls by merging multiple images into one so you can have the whole background as 1 image, indestructible world objects as 2 leaving you witch entities that you should not draw if off screen...
-canvas: a very easy way, but not supported on all systems
-spritebunch: maybe even easier, but only for tile based maps
-per pixel operations on image data: in theory the same possibilities as canvas (good math skills required) but it may take a long time to generate something large...

[scrolly]

-spritebunch: maybe even easier, but only for tile based maps

As I understand it, Pyglet takes this approach, it has a Sprite class that is impressive and uses batching.

But I think the issue was, the main loop being python, you would get these ticks that varied wildly, so movement would seem jittery. The answer was to rewrite the main loop in C? Because a scripting language inherently is going to be like this...

Anyway I may be making a big deal about something that is a non-issue..
does anyone have links to LOVE games, or demos, that show off full-screen scrolling?

[Germanunkol]

does anyone have links to LOVE games, or demos, that show off full-screen scrolling?

Yes: http://www.youtube.com/watch?v=0ztZc4SMsJ4

The game I'm currently working on with micha also does it, but we don't have any videos (yet). But it works perfectly fine, even with huge maps. When you use a sprite batch, make sure to fiddle around with the "usagehint" (some of them caused it to be slower on some systems, for us, although that seems to have been a driver bug). For starting out, you should probably just leave it at nil.

So, bottom line: Love, when used right, is more than fast enough for side-scrolling games.

[slime]

some of them caused it to be slower on some systems, for us, although that seems to have been a driver bug

Well, that's sort of the point of the usage hint - it lets the video driver make a more informed decision about where to put the SpriteBatch data, which can mean things might go slower if your actual usage doesn't match the hint you used.

[kikito]

Some time ago I did a library for handling scrolling in stuff. Its demo shows the level of smoothness achievable with LÖVE.

You can find it here:

viewtopic.php?f=5&t=12033

[Germanunkol]

some of them caused it to be slower on some systems, for us, although that seems to have been a driver bug

Well, that's sort of the point of the usage hint - it lets the video driver make a more informed decision about where to put the SpriteBatch data, which can mean things might go slower if your actual usage doesn't match the hint you used.

Well, I know that's what it's meant for, but micha had some problems that don't seem to be what was intended by the authors of newSpriteBatch.
We used "dynamic" because we changed the batch every now and then, but that became so slow that the game became unplayable.
Bottom line is though, that scrolling a 2D level in Löve works great and very quickly, with quite little effort.