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
Jake
Support Hero
Posts: 3826
Joined: Sat Jun 17, 2006 7:28 pm
Contact:

Re: Path motion

#16 Post by Jake »

I wouldn't worry about duplicated effort, since... basically, SDL doesn't do that much for you. You'd just be calling OpenGL's "draw me a textured rectangle" method instead of SDL's "draw me a sprite" method, a lot of the time. And since GL support allows you to do extra things that SDL's libraries don't have methods for, it's not directly comparable anyway. The loss of compatibility with a small percentage of users is the main argument against, really, to my eye - weighed against better performance for the majority of users.
Wintermoon wrote:Graphics cards are already becoming generic and programmable. In ten years, the GPU functionality will probably be completely integrated in the CPU anyway.
I think this is highly unlikely. It's more likely that the GPU will grow to the point that - for graphics intensive applications like games - it's doing more work than the CPU, but I doubt it will ever merge. Why? For three reasons.

Firstly, because die space - putting stuff on a chip - is expensive, and it gets more expensive at an incredible rate the more stuff you want to put on at the same time. Basically because when you etch a silicon wafer to make chips, it's almost guaranteed that there will be a certain proportion of the surface of that wafer which doesn't get etched properly and thus doesn't work. If you have 20 1-square-cm chips on that wafer and lose a square millimetre to manufacturing error, you lose one chip, 5% of the wafer. If you have 5 4-square-cm chips on that wafer and lose a square millimetre to error, you still lose one chip... but now that one chip is 20% of your wafer. So there's a distinct economic advantage to keeping your chips small, which means that since CPUs and GPUs are both growing in size and complexity, putting them both on the same die would be economically suicidal. You'd need to presume that a totally new manufacturing process with different properties is going to come along.

Secondly, just because architecturally, our current PCs don't do stuff like that and would need significantly re-designing before they could - and the PC industry doesn't tend to make drastic changes very often, if ever. It's very big on backwards-compatibility, making sure legacy devices and applications still work, and sticking to the same architectural paradigms so that they can still re-use the same old auxiliary components and so on. It's likely that this kind of change would break more things than it would fix, in this regard.

Thirdly, graphics RAM is utilised in a different manner to system RAM, which is a good reason to keep them separate - graphics RAM benefits from being quicker, the caching policy (even if hardware-implemented) will be totally different, because access patterns are different. Some portion of it needs to be directly accessed by the electronics which drive the video-out socket. So putting it all in the same place would likely mean either lower performance, or again, drastically increased price.

Now, to be fair, you do see this happening in some cases. Integrated graphics chipsets residing on the motherboard often share system RAM, but then... they also often drastically underperform compared to their PCI/AGP/PCI-E cousins. Embedded systems sometimes do have the graphics chipset on-die with the CPU, but in the case of embedded systems size is typically more important than cost and performance, so it's worth taking the manufacturing hit and the performance hit to produce something that's physically tiny.

(There are performance benefits to putting the GPU on the same silicon as the CPU; you wouldn't have to worry about a slow PCI-E bus between the two when you have a fast on-die bus instead, for example. But this is largely worked around these days by uploading texture, geometry and draw instruction data, and shader programs and so on, into the graphics card's RAM so you don't use the bus for so much anyway.)
Server error: user 'Jake' not found

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

Re: Path motion

#17 Post by Wintermoon »

Jake wrote:Firstly, because die space - putting stuff on a chip - is expensive, and it gets more expensive at an incredible rate the more stuff you want to put on at the same time. Basically because when you etch a silicon wafer to make chips, it's almost guaranteed that there will be a certain proportion of the surface of that wafer which doesn't get etched properly and thus doesn't work. If you have 20 1-square-cm chips on that wafer and lose a square millimetre to manufacturing error, you lose one chip, 5% of the wafer. If you have 5 4-square-cm chips on that wafer and lose a square millimetre to error, you still lose one chip... but now that one chip is 20% of your wafer. So there's a distinct economic advantage to keeping your chips small, which means that since CPUs and GPUs are both growing in size and complexity, putting them both on the same die would be economically suicidal. You'd need to presume that a totally new manufacturing process with different properties is going to come along.
And yet, multi-core processors are taking off and multi-CPU computer are... not. But I'm not really talking about the silicon level.

As shader programs become more and more complex, the current model of writing the shader separately from the main program and handing it off to the graphics driver becomes less and less viable. It's crap for debugging, it's crap for refactoring, and it's especially crap when you need to support different GPU architectures with different capabilities or when the driver programmer sucks at compiler programming.

I expect that in the future, graphics programs will be written as a single unified program. Then the compiler, the runtime, or even the CPU itself will decide which parts of it run on the CPU and which parts run on the GPU (or a more generalized dsp unit), adapting to different architectures and capabilities as necessary. Such a compiler is possible even with no changes at the hardware level. It just requires time, a stable platform, and a lot of effort.

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

Re: Path motion

#18 Post by Jake »

Wintermoon wrote: And yet, multi-core processors are taking off and multi-CPU computer are... not.
That's because the performance benefits of running multi-core CPUs make them attractive enough for people to pay extra, so the manufacturing losses can be written off. We did go through a phase where multi-CPU machines were desirable because multi-core was too expensive but parallelisation was still worthwhile; one of the largest avoidable inefficiencies in multi-CPU machines is synchronisation and communication between the different chips, so there was inevitably going to be an eventual transition to multi-core once manufacturing improved.

In the case of a GPU, on the other hand, it's separated logically as well as physically, so the gains from being on-die would be nearly entirely in terms of data transfer between the CPU and the GPU... which is a problem largely worked around presently by storing all that stuff on the graphics card in the first place, so all your loading time is up-front. RAM is relatively cheap, so it's a cheaper solution, and the performance gains for putting it on the same die as the CPU aren't significant.
Wintermoon wrote: Such a compiler is possible even with no changes at the hardware level. It just requires time, a stable platform, and a lot of effort.
This is all well and good for shader programming, but that's not really an argument against using OpenGL at all, since it's perfectly plausible to make good use of OGL without using shaders at all.

And... really, I think there are still problems, even if just pragmatic ones. Having such a compiler only helps debugging if you're going to run entirely in software while debugging. It only helps avoid problems caused by crap drivers if the new compiler is any better, and arguably that improvement effort could more effectively be spent on the driver instead. It doesn't really solve the varying-capabilities problem since running in software is pretty much always going to be significantly slower than running on specialised hardware, or the specialised hardware wouldn't exist, so people will still have to go through the fun capabilities-checking dance before using any of those features, since pretty much all desktop applications of shaders are real-time and performance-critical.

The gains in terms of refactoring are mostly a gain from using a high-level language instead of the practically-assembler that current shader languages embody, and I agree that sooner or later (probabaly, given trends in such matters, later) we're likely to see a move to a nice clean high-level shader language (if this hasn't already happened; I've not really looked that much at Cg, for example), and some time after that we'll see a standardised version which isn't bound specifically to one manufacturer's hardware. However, I think there's still going to be an argument for keeping the shader parts of the application separate from the rest of the application - having a clear delineation between the parts which don't have anything to do with the GPU at all and the parts which can theoretically be offloaded onto it.


So my expectation is - especially given that unlike regular parallelisation, graphics improvements only really help a relatively small market - that in the short- to medium-term, at least, we won't see complete integration at the compiler level, we'll just see a gradual improvement of shader development. If we see a total unification of graphics code that's dealt into GPU and CPU sections post-programming, then I think it's far more likely to demand the use of some existing standard hardware-agnostic API... like OpenGL.
Server error: user 'Jake' not found

delta
Epitome of Generic
Posts: 525
Joined: Sat Dec 22, 2007 12:59 pm
Projects: yes
Contact:

Re: Path motion

#19 Post by delta »

OGL or not OGL, path animations are AWESOME (I badly wanted to write that, but I never got around to wrap my head around the math required). This needs to go to the cookbook, or better yet the stock Ren'Py distro.
The rest is left as an exercise for the reader.

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

Re: Path motion

#20 Post by Aenakume »

Ah, the cookbook, ごめんなさい。i got so caught up in my next project - something EvilDragon suggested, a particle engine capable of arbitrary path motions - i even forgot i was half-way through a Python script to translate SVG paths to paths that PathMotion can use.

i'll get on all that. ^_^; ASAP, i promise!
“You can lead a fool to wisdom, but you cannot make him think.”

User avatar
DaFool
Lemma-Class Veteran
Posts: 4171
Joined: Tue Aug 01, 2006 12:39 pm
Contact:

Re: Path motion

#21 Post by DaFool »

Jake wrote: [*]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.
I buy Dells/Apples etc when abroad. But it's true in most corners of the world, PCs are built by the same backstreet stores that sell PC parts made in China. I was actually surprised when they I saw they don't even bother to burn in or test them -- they just assemble them in a hurry! Even my college friend who built PCs as a hobby would always thoroughly use diagnostic tools before selling the units to his customers.

I'd say let all drivers (if ever) needed to run Ren'Py be self-contained in the Ren'Py installation. No .NET downloads, Java runtimes, Visual development environments, even DirectX downloads please. Some of these things are many times the size of a small game, and doesn't give that 'works out of the box' feeling.

User avatar
PyTom
Ren'Py Creator
Posts: 16093
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

#22 Post by PyTom »

DaFool wrote:I'd say let all drivers (if ever) needed to run Ren'Py be self-contained in the Ren'Py installation. No .NET downloads, Java runtimes, Visual development environments, even DirectX downloads please. Some of these things are many times the size of a small game, and doesn't give that 'works out of the box' feeling.
Well, I do try for that, which is why you don't see people complaining about DLL or codec problems. But I do assume that the user has a working video driver on their computer. (Which seems like a reasonable assumption, as if they didn't, they wouldn't be able to see anything.)
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

#23 Post by Jake »

DaFool wrote:I'd say let all drivers (if ever) needed to run Ren'Py be self-contained in the Ren'Py installation.
So you want Ren'Py to be distributed as a Linux Live-CD?
Server error: user 'Jake' not found

User avatar
DaFool
Lemma-Class Veteran
Posts: 4171
Joined: Tue Aug 01, 2006 12:39 pm
Contact:

Re: Path motion

#24 Post by DaFool »

Jake wrote:
DaFool wrote:I'd say let all drivers (if ever) needed to run Ren'Py be self-contained in the Ren'Py installation.
So you want Ren'Py to be distributed as a Linux Live-CD?
That's carrying it to an extreme.

As long as a person has a working OS on a computer that doesn't look like it's in Safe Mode.

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

Re: Path motion

#25 Post by Jake »

DaFool wrote:As long as a person has a working OS on a computer that doesn't look like it's in Safe Mode.
My point is that different people have different ideas about what that means, so you can't say that anything will absolutely definitely work unless you supply the entire system yourself. Even the LiveCD wouldn't really be enough, because someone still might have a PC with a CGA video card or something which just doesn't support the video modes Ren'Py requires. To come close to guaranteeing it, you'd want to supply an airlocked temperature-controlled room with a suitable atmosphere, a battery-backed generator with ample fuel or some other reliable power source, and so on. Even then, it probably wouldn't work if the user lived on the surface of the sun!

For example: personally, I'd consider any computer of mine to not be "working" if it couldn't run OpenGL or DirectX software; you apparently think your PC works, despite not being able to do this; from what you've said, it sounds very much like a driver problem or a hardware fault. Some people consider their PC to be in perfect working order but run in a text mode all the time.
Server error: user 'Jake' not found

delta
Epitome of Generic
Posts: 525
Joined: Sat Dec 22, 2007 12:59 pm
Projects: yes
Contact:

Re: Path motion

#26 Post by delta »

Sorry to interrupt your graphics API discussion, but I'd like to talk about motion paths for a second. So I guess nobody has tried this yet? Because, uh, it doesn't work? For starters, PathMotionInterpolator does not exist. Changing it to PathInterpolator kind of works, but not for any of my image displayables (it shows nothing) - funnily enough it DOES work perfectly for one based on ParameterizedText.
The rest is left as an exercise for the reader.

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

Re: Path motion

#27 Post by Aenakume »

delta wrote:Sorry to interrupt your graphics API discussion, but I'd like to talk about motion paths for a second. So I guess nobody has tried this yet? Because, uh, it doesn't work? For starters, PathMotionInterpolator does not exist. Changing it to PathInterpolator kind of works...
Yes, that's my fault. In the code i've been testing it with, it's called BezierMotion and BezierMotionInterpolator. i figured that was a little cryptic for people who aren't into math or vector graphics, so i changed it to PathMotion and PathInterpolator when i posted it (but it's still BezierMotion in my code).

i fixed that, but i'll try copying it right from the post and using it as is later... just to make double sure. (i was gonna do that when i put it in the cookbook... i'm so bad for jumping from one project to the next >_<... but at least i sorta kinda finish each project! Sorta. ^_^)
delta wrote:but not for any of my image displayables (it shows nothing) - funnily enough it DOES work perfectly for one based on ParameterizedText.
Now that, i can't explain. ^_^; i've been using it with image displayables with no problems... and anyway, the code has nothing to do with with displaying displayables. It's just called each frame with a time and returns a position. As long as that position is in the bounds of the screen, and as long as it calculates that position in a reasonable amount of time, there shouldn't be a problem. If it works for ParametrizedText displayables, it should work for any displayables.

Are you sure your image displayables are working in general - regardless of the path? Does it work with just "show whatever at center"? Or "show whatever at Move(...)" (pick your coordinates)? If it works for those, it should work for PathMotion, too.
“You can lead a fool to wisdom, but you cannot make him think.”

delta
Epitome of Generic
Posts: 525
Joined: Sat Dec 22, 2007 12:59 pm
Projects: yes
Contact:

Re: Path motion

#28 Post by delta »

Aenakume wrote:Are you sure your image displayables are working in general
Yes, I am. I will play around with it a bit more.
The rest is left as an exercise for the reader.

delta
Epitome of Generic
Posts: 525
Joined: Sat Dec 22, 2007 12:59 pm
Projects: yes
Contact:

Re: Path motion

#29 Post by delta »

Tested further. It works, but only with small images (<300px high, though the exact threshold seems to change from start to start for some reason). When I first tried it, I used sprites (600px high). Probably a Ren'Py bug.
The rest is left as an exercise for the reader.

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

Re: Path motion

#30 Post by Aenakume »

delta wrote:Tested further. It works, but only with small images (<300px high, though the exact threshold seems to change from start to start for some reason). When I first tried it, I used sprites (600px high). Probably a Ren'Py bug.
Did they work with Move?

The only difference i can see between Move and PathMotion is that the computation for each position takes a little longer for PathMotion. Maybe Ren'Py doesn't get around to showing the image if the calculation is too long and the image is too big? You could try putting dummy calculations in PathInterpolator's __call__ to waste time and see if you can get the threshold to drop to 50px or less.
“You can lead a fool to wisdom, but you cannot make him think.”

Post Reply

Who is online

Users browsing this forum: No registered users