Path motion

A place for Ren'Py tutorials and reusable Ren'Py code.
Forum rules
Do not post questions here!

This forum is for example code you want to show other people. Ren'Py questions should be asked in the Ren'Py Questions and Announcements forum.
Message
Author
Aenakume
Regular
Posts: 182
Joined: Mon Aug 11, 2008 4:38 am
Projects: Arts... i hate arts -_-
Contact:

Path motion

#1 Post by Aenakume »

This is a motion function to move stuff around - similar to Move - that allows you to specify paths by key-frame points. Between your key-frame points, you can specify motion that is linear, quadratic or cubic.

Here's an example that uses quadratic interpolation.
Image

Code: Select all

points = (
  ((100, 300),),
  ((400, 300), (550, 450)),
  ((700, 300), (250, 150))
)

show box at PathMotion(points, 1.0)
Here's a more complex example that uses cubic interpolation to draw a lower case a.
Image

Code: Select all

a_points = (
  ((485, 238),),
  ((390, 205), (454, 212), (426, 202)),
  ((336, 289), (353, 207), (326, 247)),
  ((415, 384), (345, 331), (378, 369)),
  ((502, 373), (452, 399), (474, 391)),
  ((531, 305), (530, 355), (534, 333)),
  ((485, 208), (528, 276), (503, 205)),
  ((553, 397), (468, 210), (531, 360))
)

show box at PathMotion(a_points, 5.0)
The format for the path is:

path ::= (
segment,
{segment,}
segment
)

segment ::= linear-segment | quadratic-bezier-segment | cubic-bezier-segment

# Moves to point in a straight line
linear-segment ::= ( point, [time] )

# Moves to the first point along a quadratic curve, using the second point as the control point
quadratic-bezier-segment ::= ( point, point, [time] )

# Moves to the first point along a cubic curve, using the second and third points as the first and second control points
cubic-bezier-segment ::= ( point, point, point, [time] )

point ::= any form of coordinate that Position can take (a tuple or list of 2 or 4 members)
time ::= float (ideally between 0.0 and 1.0, but not necessarily)

Any time you don't manually specify is linearly interpolated between the previous and following times that are specified. This allows you to specify that at a specific time, the motion will be at a specific point. By default, the start time is 0.0 and the end time is 1.0, unless you specify something different.

To make paths, the easiest thing to do is to use a vector image application (i used Inkscape). This function supports all the same motion types as SVG paths except arcs (a/A). (You may have to manually specify the points that are automatically generated by t/T or s/S.) In time, i might even get around to making a helper script to convert SVG path code to path objects PathMotion can use. For now, you'll have to do it manually.

(If you're using Inkscape, it's easy because Inkscape converts all straight line types (l/L, v/V and h/H) to absolute, arbitrary lines (L), and all curve types (a/A, q/Q, t/T, s/S) to absolute, cubic Bézier lines (C). Of course, this assumes you have a single line path, which you obviously should. All you have to do is copy the "d" code, break it up by segments - easy to do because each segment starts with L or C - then delete the letters, turn all the floating point numbers to ints, and rearrange the coordinates in C lines from [a b c] to .)

Here's how to use it. Make a new renpy (.rpy) file in your game directory, and copy this into it.

[code]
init python:
class PathInterpolator(object):

anchors = {
'top' : 0.0,
'center' : 0.5,
'bottom' : 1.0,
'left' : 0.0,
'right' : 1.0,
}

# Default anchors (from Position)
default_anchors = (0.5, 1.0)

def __init__(self, points):

assert len(points) >= 2, "Need at least a start and end point."

def setup_coordinate_(c):
if len(c) == 2:
c += self.default_anchors
return [ self.anchors.get(i, i) for i in c ]

self.points = []

for p in points:
length = len(p)

if isinstance(p[-1], float):
length = len(p) - 1
point = [ p[-1] ]
else:
length = len(p)
point = [ -1 ]

self.points.append(point + [ setup_coordinate_(p) for i in range(length) ])

# Make sure start and end times are set, if not already set
if self.points[0][0] == -1:
self.points[0][0] = 0.0
if self.points[-1][0] == -1:
self.points[-1][0] = 1.0

# Now we gotta calculate the step times that need calculating
for start in range(1, len(self.points) - 1):
if self.points[start][0] != -1:
continue

end = start + 1

while end < (len(self.points) - 1) and self.points[end][0] == -1:
end += 1

step = (self.points[end][0] - self.points[start - 1][0]) / float(end - start + 1)

for i in range(start, end):
self.points[0] = self.points[0] + step

# And finally, sort the list of points by increasing time
self.points.sort(lambda a, b: cmp(a[0], b[0]))

self.initialized = False

def init_values_(self, sizes):
def to_abs_(value, size):
if isinstance(value, float):
return value * size
else:
return value

def coord_(c):
return [ to_abs_(c[0], sizes[0]) - to_abs_(c[2], sizes[2]),
to_abs_(c[1], sizes[1]) - to_abs_(c[3], sizes[3]) ]

for p in self.points:
for i in range(1, len(p)):
p = coord_(p)

self.initialized = True

def __call__(self, t, sizes):
# Initialize if necessary
if not self.initialized:
self.init_values_(sizes)

# Now we must determine which segment we are in
for segment in range(len(self.points)):
if self.points[segment][0] > t:
break

# If this is the zeroth segment, just start at the start point
if segment == 0:
result = self.points[0][1]
# If this is past the last segment, just leave it at the end point
elif segment == len(self.points) - 1 and t > self.points[-1][0]:
result = self.points[-1][1]
else:
# Scale t
t = (t - self.points[segment - 1][0]) / (self.points[segment][0] - self.points[segment - 1][0])

# Get start and end points
start = self.points[segment - 1][1]
end = self.points[segment][1]

# Now what kind of interpolation is it?
if len(self.points[segment]) == 2: # Straight line
t_p = 1.0 - t

result = [ t_p * start + t * end for i in 0,1 ]
elif len(self.points[segment]) == 3: # Quadratic Bézier
t_pp = (1.0 - t)**2
t_p = 2 * t * (1.0 - t)
t2 = t**2

result = [ t_pp * start + t_p * self.points[segment][2] + t2 * end for i in 0,1 ]
elif len(self.points[segment]) == 4: # Cubic Bézier
t_ppp = (1.0 - t)**3
t_pp = 3 * t * (1.0 - t)**2
t_p = 3 * t**2 * (1.0 - t)
t3 = t**3

result = [ t_ppp * start[i] + t_pp * self.points[segment][2][i] + t_p * self.points[segment][3][i] + t3 * end[i] for i in 0,1 ]

return ( int(result[0]), int(result[1]), 0, 0 )

def PathMotion(points, time, child=None, repeat=False, bounce=False, anim_timebase=False, style='default', time_warp=None, **properties):
return Motion(PathInterpolator(points), time, child, repeat=repeat, bounce=bounce, anim_timebase=anim_timebase, style=style, time_warp=time_warp, add_sizes=True, **properties)
[/code]

Then, you can use it in at clauses just like Move and Position:

[code]
show box at PathMotion((((100, 300),), ((400, 300), (250, 450), 0.25), ((700, 300), (550, 150))), 5.0)
[/code]

Of course, it is a little cryptic to specify your path right in there like that, so you can do this, too:
[code]
python hide:
sine_path = (
((100, 300),),
((400, 300), (250, 450), 0.25),
((700, 300), (550, 150))
)

show box at PathMotion(sine_path, 5.0)
[/code]

Tip: ^_^

When you're moving something around, it might be easier if you use the centre of the image as the anchor.
[code]
a_points = (
((485, 238, 0.5, 0.5),),
((390, 205, 0.5, 0.5), (454, 212, 0.5, 0.5), (426, 202, 0.5, 0.5)),
((336, 289, 0.5, 0.5), (353, 207, 0.5, 0.5), (326, 247, 0.5, 0.5)),
((415, 384, 0.5, 0.5), (345, 331, 0.5, 0.5), (378, 369, 0.5, 0.5)),
((502, 373, 0.5, 0.5), (452, 399, 0.5, 0.5), (474, 391, 0.5, 0.5)),
((531, 305, 0.5, 0.5), (530, 355, 0.5, 0.5), (534, 333, 0.5, 0.5)),
((485, 208, 0.5, 0.5), (528, 276, 0.5, 0.5), (503, 205, 0.5, 0.5)),
((553, 397, 0.5, 0.5), (468, 210, 0.5, 0.5), (531, 360, 0.5, 0.5))
)

show box at PathMotion(a_points, 5.0)
[/code]
Last edited by Aenakume on Thu Sep 04, 2008 7:07 pm, edited 2 times in total.
“You can lead a fool to wisdom, but you cannot make him think.”

monele
Lemma-Class Veteran
Posts: 4101
Joined: Sat Oct 08, 2005 7:57 am
Location: France
Contact:

Re: Path motion

#2 Post by monele »

I don't know *when* it'll be useful... but it looks lovely :D

EvilDragon
Veteran
Posts: 284
Joined: Fri Dec 28, 2007 5:47 am
Location: Where the Dragons rule!
Contact:

Re: Path motion

#3 Post by EvilDragon »

Combining all these moves and motions (your other topic) with particles would probably guarantee stellar results.
Angels of paradise, angels of sacrifice
Please let me be under your wings...

Aenakume
Regular
Posts: 182
Joined: Mon Aug 11, 2008 4:38 am
Projects: Arts... i hate arts -_-
Contact:

Re: Path motion

#4 Post by Aenakume »

Yes, a particle engine using some of these would be cool. Actually, i started making paths with UI elements in mind - buttons and menus spiralling in and stuff.
“You can lead a fool to wisdom, but you cannot make him think.”

EvilDragon
Veteran
Posts: 284
Joined: Fri Dec 28, 2007 5:47 am
Location: Where the Dragons rule!
Contact:

Re: Path motion

#5 Post by EvilDragon »

That is even more cool! Now to add some realtime blurring to those motions would be... awesome, to put it simply. But, I suppose we're waiting GLRenpy for that.
Angels of paradise, angels of sacrifice
Please let me be under your wings...

Aenakume
Regular
Posts: 182
Joined: Mon Aug 11, 2008 4:38 am
Projects: Arts... i hate arts -_-
Contact:

Re: Path motion

#6 Post by Aenakume »

EvilDragon wrote:That is even more cool! Now to add some realtime blurring to those motions would be... awesome, to put it simply. But, I suppose we're waiting GLRenpy for that.
Yes! i totally agree! ^_^ Earlier i was askin about matrix operations on images for just that reason. ^_-

i also was thinkin of takin the image, makin n copies with decreasing alpha, and each time the function is called, draw each copy in order of increasing alpha at each of the last n points of the motion to get a poor man's motion blur. i figured, in the init block, you'd create a MotionBlurredImage based on Displayable (just like Image and Animation are). Then you'd just use the Move or Pan or PathMotion or whatever, and it would blur itself as it moved by remembering the last n points it was drawn at.

So sweet. ^_^
“You can lead a fool to wisdom, but you cannot make him think.”

EvilDragon
Veteran
Posts: 284
Joined: Fri Dec 28, 2007 5:47 am
Location: Where the Dragons rule!
Contact:

Re: Path motion

#7 Post by EvilDragon »

I bet that principle would use up too much RAM and CPU time. That's why we need the power of today's graphics cards to do it in realtime. Shaders do it all :D
Angels of paradise, angels of sacrifice
Please let me be under your wings...

Aenakume
Regular
Posts: 182
Joined: Mon Aug 11, 2008 4:38 am
Projects: Arts... i hate arts -_-
Contact:

Re: Path motion

#8 Post by Aenakume »

EvilDragon wrote:I bet that principle would use up too much RAM and CPU time. That's why we need the power of today's graphics cards to do it in realtime. Shaders do it all :D
My god. ^_^; You kids these days are so spoiled for your fancy graphics cards! You do realize that we ran full screen, fully-animated 3D games before OpenGL, hm? ^_^; Yes, it is possible.

Taking one single image - not even a full-screen ^_^; - copying it a couple times in memory (which may not even be necessary), then blitting it three or four times is hardly gonna make your CPU start steaming. ^_^;

Hell, a full screen (800*600) image with 32 bit pixels is not even 2 MiB. Say you copy it four times... that's 8 MiB. How many gigs of RAM do you have? ^_^; A single character in a five year old 3D game is probly five times that. Hell, right now Firefox is slurping up >79 MiB. And my file manager is eating >22 MiB. And neither of these are games, which are expected to drain resources as you play them. And... ~8 million bytes added and multiplied four times is around 64 million operations (i know i'm being sloppy and way over estimating, but eh, better to guess high then low). On a 1 GHz single core processor, that should take, oh, 64 milliseconds, which will give you a 15 fps frame rate (not taking into account memory fetch times or other stuff). Not the smoothest, but hardly bad for a full screen motion blur. ^_^;

Now, a more practical example is Eileen. She's 266*600*32 (which is still pretty big to be blurring around without givin the player motion sickness), which is 642 KiB. Just a bit over a half a meg. ^_^; Copy four times for ~2.5 MiB of memory. To do the blur is ~20 million ops, on a 1 GHz single core that's 20 ms, which is 50 fps. Smooooth.

Of course, this is all extreme worst case estimates with absolutely no optimizing at all (i don't even think single core processors still exist, because even the Pentium 1 had two pipes). In reality, you can easily get a smooth full screen blur on low end hardware today without any acceleration if all you're doing is blitting alpha-adjusted copies of the screen. You could get full screen blurring on the 20 MHz, 128 KiB RAM SNES. ^_^; Granted you had fewer and smaller pixels, but still. And blurring non-full-screen sprites and buttons and stuff shouldn't be a problem at all. Plus, you're probly already getting hardware acceleration for 2D graphics anyway via SDL. Isn't that what Ren'Py uses under the hood?

Someday sooner or later i'll pry open the Displayable class in renpy/display/core.py and see if i can make it dance, just like i've been doin with Motion (other things i might do include makin simple graphing functions - to draw like line charts to plot stats and so on). i'm pretty sure that if i can get access to the raw pixels drawn to the screen, i can make a very fast blur. But for the short-term, blitting alpha-adjusted copies should do just fine.
“You can lead a fool to wisdom, but you cannot make him think.”

EvilDragon
Veteran
Posts: 284
Joined: Fri Dec 28, 2007 5:47 am
Location: Where the Dragons rule!
Contact:

Re: Path motion

#9 Post by EvilDragon »

Hey, I'm not at all that experienced in programming as I see you are, I'm just saying that it's much better to incorporate GPUs instead of putting everything to CPU. It's not that I'm spoiled (hell, I had used integrated graphics of my Gigabyte MB (Intel chipset, which is bad) up until a few days ago, when my friend GAVE me Radeon X1650, which is now obsolete, for free!) it's just that I'm practical.

Also, I'm not a kid anymore ^^' And I didn't say it wouldn't be possible, I just thought it would put a strain to RAM and CPU. Guess you proved me wrong. Still, I think it would be much better to support realtime image operations through OpenGL and graphics accelerators.
Angels of paradise, angels of sacrifice
Please let me be under your wings...

Jake
Support Hero
Posts: 3826
Joined: Sat Jun 17, 2006 7:28 pm
Contact:

Re: Path motion

#10 Post by Jake »

Aenakume wrote: You do realize that we ran full screen, fully-animated 3D games before OpenGL, hm? ^_^; Yes, it is possible.
We did, but the games in question weren't particularly 3D, were very low-res and often didn't include anything so complex as lighting, let alone alpha. ;-)

The alpha thing is a big sticking point in this comparison, because... well, it's a lot easier to blit a sprite than to draw one with alpha - it requires a drastically lower number of CPU operations to DMA this chunk of system RAM into that part of video RAM than it does to examine all those pixels and perform calculations on them. Performing alpha in CPU means either maintaining a system-RAM framebuffer, or pulling graphics data back off the videocard.

(The SNES example is somewhat irrelevant as well, since whatever the speed of the SNES' CPU, I seem to recall it had limited hardware alpha support which would have been more than enough for this kind of operation...)
Aenakume wrote: 8 MiB
Total aside, but I can never help but read this as "eight men in black"... :3
Aenakume wrote: Not the smoothest, but hardly bad for a full screen motion blur. ^_^;
Well, except that it's terrible compared to the consistent hundreds-of-frames-per-second I expect a period graphics card could manage in hardware.
Aenakume wrote: Of course, this is all extreme worst case estimates with absolutely no optimizing at all (i don't even think single core processors still exist, because even the Pentium 1 had two pipes).
(Nitpicking, but if it's an extreme worst case estimate, you should also take into account that in today's multi-tasking operating systems (which largely weren't in use back when we had full-screen 3D games without OGL :3) it's entirely plausible that the OS might be using 90% of your 1GHz CPU for something else entirely; maybe an anti-virus scan has started, or the user's playing a highly-compressed audio file in the background that takes a lot of decoding or something. Leaving aside that things like audio-playing and input polling and so on within Ren'Py will be stealing some of that processing as well. One way or another, you're highly unlikely to have 100% of the CPU's attention for your drawing, even if the user thinks they're doing nothing else.)


(And... really, pipelined processing is not the same thing as multi-core processing by a huge margin. That's like saying that bicycles are practically motor vehicles because they have gears.)
Aenakume wrote: Plus, you're probly already getting hardware acceleration for 2D graphics anyway via SDL. Isn't that what Ren'Py uses under the hood?
Hm. In my experience, at least on Windows, SDL's graphics routines are... pretty slow, actually. If they're getting hardware acceleration, they're hiding it pretty well!



Anyway - sure, fundamentally, even a low-end modern PC you shouldn't have any trouble getting a decent number of FPS doing full-screen alpha-based fake motion blur on an 800x600 image. But all the same, using even a low-end hardware solution - a GeForce 1 should be practically a given, these days, it's nine years old - will perform so much better that where it's available, it's a really good idea to take advantage of it. If nothing else, people who run games on laptops will thank you, because running it in hardware instead of ramping their CPU usage up to 100% will use up far less of their battery power. ;-)

Fundamentally, it seems to me that in 99% of cases, you're better off just using something like OpenGL for this kind of problem. Forget pixel shaders, just doing it with CPU-calculated alpha it's pretty unlikely to be noticably slower in OGL than doing it by hand, and where hardware support is available OGL will be so much faster it's not worth making the comparison. If someone has a system old enough that they can't run it, then there's a fair chance their hardware is so bad they wouldn't be able to run most entirely-software solutions either.
Server error: user 'Jake' not found

EvilDragon
Veteran
Posts: 284
Joined: Fri Dec 28, 2007 5:47 am
Location: Where the Dragons rule!
Contact:

Re: Path motion

#11 Post by EvilDragon »

Jake wrote:If nothing else, people who run games on laptops will thank you, because running it in hardware instead of ramping their CPU usage up to 100% will use up far less of their battery power. ;-)
This is a very good point.
Angels of paradise, angels of sacrifice
Please let me be under your wings...

User avatar
PyTom
Ren'Py Creator
Posts: 16088
Joined: Mon Feb 02, 2004 10:58 am
Completed: Moonlight Walks
Projects: Ren'Py
IRC Nick: renpytom
Github: renpytom
itch: renpytom
Location: Kings Park, NY
Contact:

Re: Path motion

#12 Post by PyTom »

OpenGL is a mixed blessing at best, though. With software graphics, older systems run a game slowly, but generally linearly so. If a computer has half the CPU power, it gets half the framerate. OTOH, if a system doesn't have OpenGL support, performance just dies compared to the OpenGL system. (What's worse, it's actually pretty hard to detect what sort of OpenGL support a system has.)

I'm still someone torn trying to determine if, in 2008, the target audience has good enough OpenGL 1.1 support to be worth trying to use that. OpenGL 2.0/Shaders seems to be too advanced for the relatively conservative VN community.

While SDL has hardware acceleration, it only works in fullscreen mode, and even then only on some computers. I actually disable it in Ren'Py, and use a software path which clocked as faster than the small amount of HW acceleration possible with SDL.

(I suspect that the VN market is such that if the choice is downloading megs of drivers or just not playing a game, many people will just not play the game.)
Supporting creators since 2004
(When was the last time you backed up your game?)
"Do good work." - Virgil Ivan "Gus" Grissom
Software > Drama • https://www.patreon.com/renpytom

Jake
Support Hero
Posts: 3826
Joined: Sat Jun 17, 2006 7:28 pm
Contact:

Re: Path motion

#13 Post by Jake »

PyTom wrote: I'm still someone torn trying to determine if, in 2008, the target audience has good enough OpenGL 1.1 support to be worth trying to use that. OpenGL 2.0/Shaders seems to be too advanced for the relatively conservative VN community.
OGL2, I would certainly agree with. OGL1, though? Windows-wise, at least - since I'm fairly convinced this is the majority of the audience - as I understand it anyone who has bought a Dell this century should have no trouble running an OGL1 app. And for Dell, I expect you could include IBM/Lenovo or HP or Toshiba or Gateway or Mesh or any other mainstream pre-fab PC manufacturer. The default drivers for ATi or nVidia graphics cards support at least the main part of OGL out of the box. Sure, they have varying support for extensions and and so on, but just for drawing alpha-blended textured rectangles...

My expectation is that the vast majority of the people who have problems running basic OGL stuff are:
  • People who have very old PCs - in 2000, I seem to recall a 500MHz PC was quite a reasonable machine; older than that, you're likely going to have trouble doing full-screen alpha in software anyway, so it's not really worth considering supporting this kind of feature for these users at all.
  • People who are running Linux - who frankly deserve everything they get are statistically more likely to be technically-minded and more willing to try and solve these problems.
  • People who have custom-built PCs with messed up/no drivers - which is the one set of people I'm curious to know the size of. People who put their own boxes together in the UK are usually in the same camp as the Linux people; they can and will fix their own problems when they arise. Is this the same for the rest of the world? This category, of course, also includes "bought PC from dodgy backstreet computer retailer", which I gather is more prevalent in some corners of the planet than mainstream operators like Dell.
Of course, the other category I can think of is "people playing games at work", and personally... while I'm not going to launch into some moralising preaching or anything, I'm less inclined to support them than home users for stuff I've written. Any problem which exists because - for example - you don't have administrator rights on your computer to upgrade the drivers, isn't actually a problem, almost by definition.
Server error: user 'Jake' not found

Aenakume
Regular
Posts: 182
Joined: Mon Aug 11, 2008 4:38 am
Projects: Arts... i hate arts -_-
Contact:

Re: Path motion

#14 Post by Aenakume »

PyTom wrote:While SDL has hardware acceleration, it only works in fullscreen mode, and even then only on some computers.
Well that sucks. i assumed that was one of its selling points. Oh well.
PyTom wrote:I'm still someone torn trying to determine if, in 2008, the target audience has good enough OpenGL 1.1 support to be worth trying to use that.
i don't know if my opinion matters, but i wouldn't bother. The average Ren'Py game has... what... 10 bitmap sprites per screen (as a fairly high estimate - some games, like Magical Boutique, might top 30, but most of those pixmaps are tiny)? Background, two characters, boxes for text and character name, ctc cursor, three buttons if there's a choice. GL could get the GPU to do the combining, and maybe some of the other functions, like zooming, but that's hardly much for the GPU to do. After paying to move all the bitmaps onto the GPU RAM, i don't know that you'd see any improvement. Most of the graphics operations Ren'Py does are highly decoupled vector operations, and modern CPUs are designed to do those scorchingly fast with MMX (even first generation Pentiums with a single core and two pipes look like a dual core when they have decoupled data and they're only doing simple integer math operations), SSE and so on.

Some people are probly already getting hardware acceleration anyway. On Windows, some of the higher end graphics cards hook the OS's draw functions and do them in the GPU (and my info's old, so maybe on Vista that's always done). And X accelerates everything if you're usin GLX or something similar, so they'll be happy too. i don't know about Macs.

So, Ren'Py's graphics are already hardware accelerated, sorta kinda, and a graphics card isn't gonna add much. The only real pro for GL is that the GPU can do the work instead of the CPU... but other than the graphics, what the hell is Ren'Py doing that requires significant CPU time? ^_^; No matter what i did - rolling back and forth, clicking as fast as i could, i couldn't get Ren'Py to use more than 22% of my processor time (and this was using the version of the default game that tests out the path motions from this thread). If you're playing a game, it's pretty much a given that you expect it to take a chunk of the CPU, but Ren'Py isn't taking all that much - even when animating according to a complex equation being calculated in real time, it wasn't that big a deal. When you minimize it or defocus it, it probly won't even make even an old system visibly slower.

If you start supporting GL, that means the user has to have a working GL driver on their comp. As it stands now, anyone with a compatible OS can run Ren'Py - even if their GL driver is broked or missing. Turning on GL would cut out people who don't have GL working - which is probly only a tiny number. So it's no great loss if you need GL acceleration, or if it makes a significant difference... but if it's gonna make no noticeable difference at all, why cut them out?
“You can lead a fool to wisdom, but you cannot make him think.”

Wintermoon
Miko-Class Veteran
Posts: 701
Joined: Sat May 26, 2007 3:41 pm
Contact:

Re: Path motion

#15 Post by Wintermoon »

Aenakume wrote: i don't know if my opinion matters, but i wouldn't bother. The average Ren'Py game has... what... 10 bitmap sprites per screen (as a fairly high estimate - some games, like Magical Boutique, might top 30, but most of those pixmaps are tiny)?
Or thousands, if each text character is counted separately. Efficient rendering of rapidly changing text is surprisingly difficult.
Aenakume wrote:Some people are probly already getting hardware acceleration anyway. On Windows, some of the higher end graphics cards hook the OS's draw functions and do them in the GPU (and my info's old, so maybe on Vista that's always done). And X accelerates everything if you're usin GLX or something similar, so they'll be happy too. i don't know about Macs.
SDL does all software rendering internally. The internal buffer is then sent to the OS in a single operation. Accelerating that single operation isn't going to do much.

Personally I'd rather stick with software rendering because:
  • It works. OpenGL still doesn't in some cases.
  • It's fast enough for most purposes, and it's only going to get faster. Especially if the software renderer is modified to take advantage of multi-core CPUs.
  • The next major release of SDL will have 3D accelerated backends, so switching to OpenGL now may lead to duplicated effort.
  • Graphics cards are already becoming generic and programmable. In ten years, the GPU functionality will probably be completely integrated in the CPU anyway.

Post Reply

Who is online

Users browsing this forum: No registered users