Is anyone planning to continue the necessary improvements for SDT? (1 Viewer)

[Pururu]

Konashion's gone. LONG gone. Someone needs to keep the game alive.

 

[stuntcock]

Lag is driven almost exclusively by graphics. As in "the number of things which are shown onscreen at the same time". Add a shirt? FPS takes a hit. Add a hat? FPS takes a hit. Toss in a few fully-shaded semen strands? FPS dies in a fire.

The game is CPU-gated, but not in a manner that modders can effectively do anything about. For example, there are a lot of mods which run minor update calculations on a per-frame basis. This is usually extravagant; we can cut the calculations down to "once per ten frames" and achieve nearly-identical results. But such calculations are not a significant source of lag, so we gain nothing by throttling them. I ran some ad hoc tests while working on hair physics. Even when a hairstyle is composed of absurdly simple graphics (i.e. colored tubes), the physics calculations involved in "deciding how the hair strands ought to move around" constitutes at most 3% of the surplus CPU load, while "drawing the ugly-ass tubes onto the screen" eats 97%. Flash isn't very good at drawing a heavily-composited scene at high detail (at least ... not if you want it in real time).

We could improve performance by merging some of the graphics together and reducing the number of layers, but this would come at the cost of the game's modularity. For example, instead of drawing the girl's arm and then drawing a shirt sleeve on the layer above it, we could import a single pre-baked [arm+sleeve] sprite into the game. But then you'd lose the ability to re-tint the girl's shirt or alter her skin tone.

The trend in SDT modding has been towards increased customizability. For example, @sby's template extension adds a half-dozen layers, for the sake of new clothing combinations (e.g. shirt+hoodie). I had to similarly add layers in order to allow a bikini strap to pass between the shoulder and neck. Pim_gd has added new dialogue triggers and an open-ended scripting system to support a huge variety of interactive narratives.

• we don't have the original SDT source code
  • patching or replacing sections of the code is possible (I've done so with the hair physics; @sby has revamped the scene layout and animation; Pim_gd has expanded the dialogue system) but the result rarely improves the game's performance
  • because we don't have the original code, we're forced to patch around it. @ModGuy's lProxy system is a huge boon here (especially in terms of inter-mod compatibility), but actual optimization passes (such as loop rewrites or data structure overhauls) are very risky.
• people have proposed porting the game to a new platform or engine
  • these projects tend to fizzle out
  • to paraphrase someone (possibly @ModGuy ?): "people who are capable of completing these projects don't start them, because they understand that it's a huge task. People who don't understand the scope will start out full of optimism, but will be disappointed when senior SDT modders aren't eager to get involved, and they'll eventually get buried by the huge workload."
• a major optimization project (or a full re-write) would involve a significant time investment, and there's no feasible way for anyone to be recompensed for their time
  • they'd be building on the work of hundreds of different people, not to mention the copyrighted girls themselves ... untangling the IP rights would be a total clusterfuck
• any optimization or rewrite project would quickly face a painful choice
  • do we attempt to include backwards compatibility for existing SDT content, or do we "cut the umbilical cord" and setup fresh systems for everything?
    
  • if you include backwards compatibility then your design is going to be riddled with compromises (i.e. susceptible to bugs) and your performance will probably be shitty
  • if you don't include backwards compatibility then there's a risk that people will look at your optimized-but-content-barren game and say "nah, I'll stick with the old SDT instead".
    • also - many of the existing modders and artists will feel betrayed (because you're effectively asking them to re-create all of their stuff again) so there would be distrust and resentment against your project from within the fanbase. Even moreso if you're somehow getting paid for the rewrite project and they're being asked to update their stuff pro bono.

So ... what do you want us to actually do?

 

[Pim_gd]

The biggest performance gain is not to be had by messing about with the game, I think. Drawing eats a LOT of the CPU time, so any improvements we make on other fronts is likely to not be noticeable.

If you want SDT to run faster, you'll have to bother Adobe to make Flash use multiple cores for their rendering, or make use of the GPU.

I had a quick look; they do have multithreading, but only for code. It's intended to allow you to send async requests to servers and such, or do calculations. So... yeah...

---

Why multi core processors?

So why do we need multi-threading at all - can't we just buy better CPU's?

Well no, if you'll check the link and search for things like "transistor size limit" and "cpu power dissipation"; you'll find out that apparently, the more gigahertz you need, the more power you'll take. And it's not a linear relationship. It seems be more like "add 25% more ghz, need 100% more power". Hertz stands for "frequency", and for CPU's it's "frequency of changing logic gates", or something like that. Basically, "how many times this CPU can change its internal state per second". That's important, because if you need to run a piece of code, then each instruction constitutes at least 1 state change (gotta move to the next instruction). And for changing bits, well, those are changes of state too. I'm pretty sure this explanation isn't 100% correct, but basically, more hertz is more things per second. Drawing things on screen is doing things, and getting more fps means the same amount of stuff ("1000 items to draw") needs to be drawn more times in a single second (1000 things once a second = 1000 things drawn per second; 1000 things drawn 30 times per second = 30000 things drawn per second). ... and drawing things is obviously more than 1 state change.

"Who cares about the power usage? I've got a vacuum cleaner and a oven at my house, and they both pull like 2500 watt, and my computer just pulls 200 - can't they make like a special 1200 or 2500 watt eating computer 'for hardcore gamers'?"

Have you felt the air that comes out the back of a vacuum cleaner? It's warm. Have you felt the air coming out your oven? It's warm. Other things that eat a lot of power are water heaters (which make things warm), microwaves (which make things warm), induction cooking (which makes things warm), growing special kinds of plants using warm lamps (which make a lot of light, aaand make things warm).

Heck, old lightbulbs got hot. New ones take less power and get less hot. Hmm.

It turns out that if you draw a lot of electrical power, it generates heat. And you gotta get rid of this heat, else it becomes dangerous for humans.

"But what if we put the computer away from the humans, like we do with ovens? You can make it hot enough in an oven to cook meat without actually cooking the humans in the house."

Good question; Why don't we just put the computer in a big box that can handle the heat?

Well...

Most electrical components don't like heat - at about, say, 80-90 degrees celcius, a lot of em will start going bad. There's special components out there that can take more heat, but even those have issues at 150 degrees. ... oh, and once you get to about somewhere 200-250, the metal that we use to glue components together in a way that electrical charge can pass between the components... it starts melting. And if it connects where it shouldn't (typically with the pin next to it, less than a millimeter away), then the components stop working properly.

The CPU can handle 90 degrees because CPU designers know it will get really hot, but other components in your computer may not be rated for this temperature. And in an oven, everything gets hot (not just the heating element).

"Yeah, but I bet we could still get a significant performance boost."

I failed to mention one other factor.

When transistors get hot, it becomes harder to change state. More energy is required to switch between on and off - kinda like you working on a hot day.

Except that if you take more energy... you get hotter.

Which means that if you go over the limit of what you can cool, and then your limit of what you can do before you generate more heat than your cooler can handle drops. And the more you go over the limit, the faster this happens.

Here's an article talking about that, they tested some intel CPU. Impact of Temperature on Intel CPU Performance

Oh, remember the "25% more speed = 100% more power usage"? Comparing it to the graphs, it seems that if you cannot cool this heat down to what the CPU is rated for, you quickly lose 10%, 20%, 30% speed. Failing to keep it cool at all makes it work at 25% of the original speed.

Say you have a 3ghz CPU now and you can handle 8x more power usage. You could get 25% more speed, 3.75ghz for 2x power. 25% more speed, 4.68ghz for 4x power. 5.85ghz for 8x power.

For this "less than double cpu speed", you get 8 times more power usage. Right now I have multiple cooling fans and a massive block of metal shaped in a way to allow for maximum heat dissipation to keep my CPU cool. I have no idea what we'd need for 8 times the power usage; probably liquid cooling. And/or more powerful fans. That make a lot of noise. It'd be unsuitable for an office environment. Heck, it'd be annoying to have to hear those fans blowing all the time.

Plus, that's probably gonna be a really pricey CPU. And there's quite the lack of market for this; just about all operating systems these days intended for general use support multiple cores, because users will run more than 1 process at the same time (e.g. listening to music whilst webbrowsing). And in those cases, you could just add another CPU next to the original one... and get 6ghz for 2x power.

Single-core programs cannot scale. 2x power consumption for 1.25x speed is something that doesn't scale well. Heck, translate it into money and you'll see where the problem is; $50 CPU 3ghz, 5.85ghz for $400. We can cheat and say it doubles; 6ghz for $400, 12ghz for $3200, 24ghz for $25600, 48ghz for $204800.

---

What this means for SDT is that it's not likely that hardware will improve. Maybe we will see a return of 4ghz multi-core processors as engineering tricks get the energy required down even more. Maybe even 4.5ghz. But 8ghz and up is just a fantasy for the coming few years. I think we'd see 32 core processors before we'd see things like single core 8ghz processors. ... a quick google later shows that 32 core processors already exist. So do 64 core processors. They're for super computers. They're 1ghz cpu's, but that doesn't matter when you pull 64 ghz in total. Plus, if we pull the same trick in reverse (20% less speed, half the power cost) then dropping from 3ghz to 1ghz is along the lines of a 16x power cost reduction.

The mods will not improve performance because its the rendering that causes CPU load.
The hardware will not improve performance because single core cpu can only go so far (and if you get 6 fps and you want 30 you need a 5x speed boost which is just no)
The software - well, that's Adobe's job. And it's not very likely - adding multi-threading support is usually one of the hardest features to implement.

So on FPS side; we're screwed. There is no solution that will scale. If I could wave a magic wand to get the game to use half of what it does right now, you'd be back where you started once you have double the strands. For problems like this to disappear, you want to change the scaling, not the size of the factors. And there is no such solution available right now.

---

also I need to stop getting baited into writing long posts by myself

 

[Pururu]

Thanks for clarifying!

So to sum it all up:
Improving SDT is not impossible, but it is a hassle to do so due to our current adobe flash player running the SDT.

 

[Pururu]

Lag is driven almost exclusively by graphics. As in "the number of things which are shown onscreen at the same time". Add a shirt? FPS takes a hit. Add a hat? FPS takes a hit. Toss in a few fully-shaded semen strands? FPS dies in a fire.

The game is CPU-gated, but not in a manner that modders can effectively do anything about. For example, there are a lot of mods which run minor update calculations on a per-frame basis. This is usually extravagant; we can cut the calculations down to "once per ten frames" and achieve nearly-identical results. But such calculations are not a significant source of lag, so we gain nothing by throttling them. I ran some ad hoc tests while working on hair physics. Even when a hairstyle is composed of absurdly simple graphics (i.e. colored tubes), the physics calculations involved in "deciding how the hair strands ought to move around" constitutes at most 3% of the surplus CPU load, while "drawing the ugly-ass tubes onto the screen" eats 97%. Flash isn't very good at drawing a heavily-composited scene at high detail (at least ... not if you want it in real time).

We could improve performance by merging some of the graphics together and reducing the number of layers, but this would come at the cost of the game's modularity. For example, instead of drawing the girl's arm and then drawing a shirt sleeve on the layer above it, we could import a single pre-baked [arm+sleeve] sprite into the game. But then you'd lose the ability to re-tint the girl's shirt or alter her skin tone.

The trend in SDT modding has been towards increased customizability. For example, @sby's template extension adds a half-dozen layers, for the sake of new clothing combinations (e.g. shirt+hoodie). I had to similarly add layers in order to allow a bikini strap to pass between the shoulder and neck. Pim_gd has added new dialogue triggers and an open-ended scripting system to support a huge variety of interactive narratives.

• we don't have the original SDT source code
  • patching or replacing sections of the code is possible (I've done so with the hair physics; @sby has revamped the scene layout and animation; Pim_gd has expanded the dialogue system) but the result rarely improves the game's performance
  • because we don't have the original code, we're forced to patch around it. @ModGuy's lProxy system is a huge boon here (especially in terms of inter-mod compatibility), but actual optimization passes (such as loop rewrites or data structure overhauls) are very risky.
• people have proposed porting the game to a new platform or engine
  • these projects tend to fizzle out
  • to paraphrase someone (possibly @ModGuy ?): "people who are capable of completing these projects don't start them, because they understand that it's a huge task. People who don't understand the scope will start out full of optimism, but will be disappointed when senior SDT modders aren't eager to get involved, and they'll eventually get buried by the huge workload."
• a major optimization project (or a full re-write) would involve a significant time investment, and there's no feasible way for anyone to be recompensed for their time
  • they'd be building on the work of hundreds of different people, not to mention the copyrighted girls themselves ... untangling the IP rights would be a total clusterfuck
• any optimization or rewrite project would quickly face a painful choice
  • do we attempt to include backwards compatibility for existing SDT content, or do we "cut the umbilical cord" and setup fresh systems for everything?
    
  • if you include backwards compatibility then your design is going to be riddled with compromises (i.e. susceptible to bugs) and your performance will probably be shitty
  • if you don't include backwards compatibility then there's a risk that people will look at your optimized-but-content-barren game and say "nah, I'll stick with the old SDT instead".
    • also - many of the existing modders and artists will feel betrayed (because you're effectively asking them to re-create all of their stuff again) so there would be distrust and resentment against your project from within the fanbase. Even moreso if you're somehow getting paid for the rewrite project and they're being asked to update their stuff pro bono.

So ... what do you want us to actually do?

I wanted you guys to take it to the next level and port the game to another engine where it could run lag-free.
Sadly, as you've said, it's a LOT of hardwork, so I can't expect anything to happen when even I the OP cannot contribute.

 

[The Hacker Known As Snow]

I wanted you guys to take it to the next level and port the game to another engine where it could run lag-free.
Sadly, as you've said, it's a LOT of hardwork, so I can't expect anything to happen when even I the OP cannot contribute.

There have been at least two people who've tried that I can remember, both on the old site.

One of them DoomKnight I think was their username, was planning to teach himself programming and then port the game to Unity. He was calling it Ultimate Deepthroat. He made posts all the time even started a blog, I wish I had the link to but the community wasn't impressed I guess.

There other I forget their name, they wanted to make SDT with html5 I think. They wanted it mostly web based, all the mods could be shared to a site and you could browse for them in game. They made one thread once were they showed an early proof of concept. After that they'd drop by randomly and just chat in the shout box. I thought that he was really proficient, he asked for ideas and had them working in a day or so.

Does anyone else remember these guys?

 

[stuntcock]

Does anyone else remember these guys?

@detritus asked about it a few weeks ago; he wanted to extract some of the vector art and try to assemble a proof-of-concept framework (using a language with higher performance, of course). I looked for the two threads that you mention but couldn't find either of them. They were presumably lost during the forum migration, or deleted during the cleanup+reorganization work which followed.

I tried to be fairly careful during those operations, only deleting the truly worthless threads (like "plz giv pasword for Loader borad" or "how do I switch to first-person view?"). But it's always possible that I deleted something valuable due to carelessness.

Both of the people went inactive long ago, and IIRC source code was never shared via a public repository. Even if the threads existed today, they wouldn't be hugely useful for actual architecture+coding stuff (although they might reveal a few missteps to avoid repeating). We'd basically be starting from scratch anyways.

 

[Pururu]

There have been at least two people who've tried that I can remember, both on the old site.

One of them DoomKnight I think was their username, was planning to teach himself programming and then port the game to Unity. He was calling it Ultimate Deepthroat. He made posts all the time even started a blog, I wish I had the link to but the community wasn't impressed I guess.

There other I forget their name, they wanted to make SDT with html5 I think. They wanted it mostly web based, all the mods could be shared to a site and you could browse for them in game. They made one thread once were they showed an early proof of concept. After that they'd drop by randomly and just chat in the shout box. I thought that he was really proficient, he asked for ideas and had them working in a day or so.

Does anyone else remember these guys?

I've heard of DoomKnight before.

 

[DKOC]

The other user was called "RC", and the reason the thread can't be found is because way back when RC stopped supporting it, Modguy, locked the thread and moved it over into the "SPAM" section of the forum. And as nothing from the "SPAM" forum made it in the transfer, that is why it can't be found.

As for the rendering, couldn't something similar to "Occlusion Culling" be used here to only render the top-most layer of the image?

 

[stuntcock]

As for the rendering, couldn't something similar to "Occlusion Culling" be used here to only render the top-most layer of the image?

Yes, but:

• it's not always appropriate to cull everything below the topmost layer. Partial-alpha transparent fills are sometimes used for skin sheen, hair highlights, saliva on the penis, and so on. Users can also manually reduce alpha values (via ARGB sliders) to create semi-transparent clothing.
• most layers don't overlap completely. In the case of an arm with a sleeve over it, we could cull part of the arm (e.g. bicep) but we'd still need to show the elbow, forearm, wrist, etc.
  • AFAIK there's no native method to do this while preserving vector details (and internal elements). We could convert everything to bitmaps and merge them (trivial) but then we'd lose the ability to adjust clothes RGB, skin tones, etc...
    
  • Workaround: we could presumably generate the merged bitmap, hide the vector art elements, draw the bitmap at the appropriate point in the visual hierarchy, and retain the merged shape only during actual gameplay. When a menu action is performed (e.g. remove bra or change Tan settings), we'd discard the bitmap, revert to the original vectors, make the usual change, and then repeat the bitmap-merge operation.
  • Problem: this approach would have poor inter-mod compatibility. Many mods interact directly with scene elements (e.g. her.rightArm), so you might get weird flickering as the optimization mod fights against a bodyshape mod.
• this approach wouldn't work at all for the most performance-intensive element: strands. They don't obey template boundaries, so the bitmap-conversion trick wouldn't work.
• this approach wouldn't work for physics-based stuff (dynamic hair and clothes) because those elements don't maintain a static shape. If you convert them to bitmaps then they'd gain great performance, but all of the animated behavior would be lost.

 

[DKOC]

Okay. Thanks for the indepth reply stuntcock. Clearly, it isn't as simple as I originally assumed.

Couple other questions:
1) Can the 3D API called Stage3D be implemented into SDT? It supposedly has support for GPU-accelerated rendering, that if it could be used here could be a potential gain in framerate.
2) Is Adobe AIR more powerful than the web-browser based Flash Player? Could SDT be built or modded in some way to utilize Adobe AIR instead?
3) Could the entirety of SDT be imported wholesale into something like Unity or UE4, in the first place? Since these engines do use Scaleform, which uses SWFs, its plausible that they could be ported wholesale into them; plus I believe (at least with UE4) they support Vector Graphics and 2D Animation support.
4) If UE4 or Unity can run SWFs, could the SDT swf be embedded into a Unity / UE4 project and have that engine do the rendering and calculations for the SWF file, instead of having a flash player or adobe AIR doing the rendering/calculations. Thus, my question is would it be possible to get framerate gains by having an actual game engine do the work?
5) Would each of these above solutions require the original FLA?

 

[stuntcock]

1) Can the 3D API called Stage3D be implemented into SDT? It supposedly has support for GPU-accelerated rendering, that if it could be used here could be a potential gain in framerate.

I doubt that we could achieve anything significant without the original source code. Any gains would be dependent on spiltting the graphics out onto separate stages (e.g. "girl's left arm", "girl's right arm") instead of the existing layers. The GPU might then be able to speed things up by handling layer occlusion stuff, but I can't promise that that's true.

The conversion would break any mod which directly interacts with scene layers. For example: the dynamicHairExtender mod does so. It would be relatively straightforward for me to fix the dynamicHairExtender mod, but there are many SDT mods which aren't being actively maintained (and/or mods whose source code was never shared). Major changes to the game's structure would render such mods inoperable. Heck - some of them get broken through evolutionary development without any radical re-writes (example: TwiceTest.swf).

2) Is Adobe AIR more powerful than the web-browser based Flash Player? Could SDT be built or modded in some way to utilize Adobe AIR instead?

Not sure. As I understand it, Flex and AIR are more about "cross-platform" stuff - getting your app to run in a protected environment, ensuring that your UI automatically scales to the appropriate aspect ratio, managing encryption+signing credentials when you need to transmit data across secure networks, allowing your app to be installed without goofy APK side-loading bullshit, allowing fullscreen mode on devices which normally prohibit it, accessing the local filesystem (or a full-fledged database - for business apps), reading data from embedded GPS or accelerometer, and so on.

3) Could the entirety of SDT be imported wholesale into something like Unity or UE4, in the first place? Since these engines do use Scaleform, which uses SWFs, its plausible that they could be ported wholesale into them; plus I believe (at least with UE4) they support Vector Graphics and 2D Animation support.

Scaleform is licensed software. I don't know enough about it to make a serious technical assessment, but I think that the performance improvement potential relies on compile-time optimization. That is -- the Scaleform library scans through the SWF and exports its assets.

The obvious problem here is that we could optimize the native SDT assets, but anything added via an external SWF (such as hair, clothing, tattoos, etc) would be un-optimized. More importantly, I doubt that the Loader would even be possible under this approach - the optimization process would probably remove our ability to randomly inject foreign objects onto the stage at runtime. So we'd need to either gather everything into a massive modpack (like the 666 girls pack) and compile it as a single optimized file ... or every SDT modder would need to buy a Scaleform license.

Either way, we'd suffer a big reduction in the openness and accessibility of the SDT modding scene.

4) If UE4 or Unity can run SWFs, could the SDT swf be embedded into a Unity / UE4 project and have that engine do the rendering and calculations for the SWF file, instead of having a flash player or adobe AIR doing the rendering/calculations. Thus, my question is would it be possible to get framerate gains by having an actual game engine do the work?

Scaleform was included in UE3 but has been dropped in UE4. Unity requires third-party tools, which seems to import+preserve animation details (colors, shapes, keyframes, positions, tweens, etc) while discarding the actual logic (penetration depth, strand physics, etc). Because you're supposed to be writing that stuff in the managed scripting environment of your Unity IDE.

It's a valid starting point for a "rewrite the whole damn game" project, since we'd have most of the vector artwork in place (a few things, such as the girl's neck, are drawn "manually" in AS3 code via brushstrokes - but that's a minor tangent). And it would deliver enormous performance improvement. But it would still involve weeks or months of unpaid work, on the basis of very dubious IP. @Konashion never actually gave anyone permission to repackage and rerelease his work; we've just been skirting around the grey area because we're distributing mods.

And it would almost certainly break compatibility with existing SWF mods. We could write a new modding framework, under which external scripts and sprites could be imported at runtime ... but someone would need to manually convert and update each of the existing SWF files.

5) Would each of these above solutions require the original FLA?

UE4/Unity - no, since we'd just be ripping the artwork and then rewriting most of the game's code.

Flex/AIR - yes, because we'd need to recompile and repackage.

Stage3D - yes, in practice. It's theoretically possible to splice in a Stage3D rejig without touching the original code, but it would introduce so many bugs (and necessitate so many patches) that nobody would use it for more than thirty seconds.

----------------​

Edit: after re-reading this post, I've noticed that it seems unreasonably critical or dismissive of your ideas. That was not my intent. So let's emphasize three things:

1. This whole topic is outside my area of expertise. Most of my own work involves desktop software for business applications. I'm providing a first-glance assessment for many of these suggestions. Please feel free to ignore my rebuttals and do your own research. If anyone out there has experience in mobile development or Unity/UE4 animation or whatever I'd encourage you to contradict my bullshit and offer better answers.
   
2. I personally wouldn't spearhead a "rewrite the whole damn game" project because I'm not comfortable taking ownership of someone else's work. Others may interpret the situation differently. If someone else wants to start such a project, then I'm willing to offer limited technical assistance and design suggestions.
3. There's potential for rapid progress on an optimization or rewrite project, by using licensed software (such as ScaleForm). I personally don't believe that this would be appropriate an appropriate path for SDT, because the licenses are quite expensive. Thus, we'd either shrink the pool of modding talent, or force all modders to engage in software piracy. I think that it's inappropriate to pursue modding projects unless there's a free option available (example), but this is merely a personal attitude. It's not a site rule.
   
   • You're free to disagree with me and pursue your own course.
   • For example: it would be perfectly valid to grab an evaluation copy of ScaleForm, import SDT.swf, and see how far you get with a proof-of-concept conversion/acceleration project.
     
   • Please double-check Undertow site rules regarding software piracy. Remember that illicit material should not be hosted on the Undertow fileserver. This could mean that (for instance) a WIP demo of your project would need to be shared via an external filehost -- because your ScaleForm evaluation EULA forbids distribution of output files.
     
   • If anyone is pursuing a rewrite project, then I would encourage them to consider open-source libraries. For example: DragonBones could easily replace the (arcane and confusing) hair physics system with something much more approachable and extensible.

 

[DKOC]

No offense taken at all. I appreciate you taking the time to fully explain how each wouldn't work. I can also see why others haven't tried doing it themselves due to the three major problems with that venture (1. Compensation/Recognition for Massive Workload, 2. Possibility of Alienating Current Playerbase, and 3. Making a Game in General is Tough; Making a Customizable Physics-Driven Game is even worse).

I have no interest in doing the work and was simply putting ideas out there in case something was overlooked and could be implemented to provide some kind of framerate boost. If I personally were to do it, I likely wouldn't use Vector Art. I don't understand how that is done, nor do I know anyone personally that can do Vector Art. I am much better at doing 3D Modelling/UV Textures, than 2D Painting, which would mean that it would essentially be its own thing.

However, right now, I'm bogged down with making a commercially sellable (non-porn) RTS in UE4, and I can honestly say that I can definitely understand why people haven't attempted a port-effort for SDT. Things that one thinks are simple to implement are often not at all simple; hell it took me over 3 weeks to figure out how to properly setup the RTS camera with panning, rotating, zooming, edge scrolling, and mouse cursor locked to the screen. I had assumed that that would be a simple implementation detail, but it wasn't. A lot of the functionality in SDT may appear "simple" at first glance, but may be a horrid pain to actually implement in something other than flash, like strand physics; yes you could use metaballs for 3D, but if the engine used tried to maintain 2D, I'd have no idea how to implement, the equivalent of metaballs in 2D.

The only reason I might do it is because at a future date, (ie 2+ years from now, after the RTS is finished), I'd like to have an Open-World Third-Person RPG, with sex in it, and thus developing a side-prototype with just the sex in it would be worth the effort to do it.

 

[stuntcock]

I have no interest in doing the work and was simply putting ideas out there in case something was overlooked and could be implemented to provide some kind of framerate boost.

That's valid, and appreciated. Most SDT modders have given up on the idea of performance improvements and so they may overlook a simple option. Suggestions are always welcome.

If I personally were to do it, I likely wouldn't use Vector Art. I don't understand how that is done, nor do I know anyone personally that can do Vector Art.

It's fairly easy. You can literally create things by tracing a reference image. Every hairstyle that I've made was done by tracing; I've attempted a few projects which involve incomplete references (hence: more artistic interpretation) and they've failed - because I don't have any actual skill at drawing things.

I am much better at doing 3D Modelling/UV Textures, than 2D Painting, which would mean that it would essentially be its own thing.

This is valid; there's nothing stopping someone from creating a spiritual-successor project in 3d. I can foresee a few obvious challenges:

• Unique Selling Point. The 3d sex-sim genre already includes TK17, various Illusion games, Skyrim modpacks, and various specialty titles for specific fetishes (bondage, tentacle, furry, etc). These games have well-established modding communities and significant libraries of custom content. A new title would need to attract players (and modders) via some unique selling point ... or a huge across-the-board improvement in quality and customizability.
  
• Performance. SDT has performance problems because it makes inefficient use of available resources; 3d games can encounter performance problems because of feature creep and over-enthusiastic modders (4k textures everywhere! Scrotums with 3000 polygons! Realtime earlobe physics! Oculus Rift support!). As you pointed out, fluid modeling is a significant challenge.
  
• Uncanny Valley. Minor deficiencies in characters proportions, lens geometry, or skin shading can turn a 3d erotica scene into a creepy spectacle.

A lot of the functionality in SDT may appear "simple" at first glance, but may be a horrid pain to actually implement in something other than flash

I disagree; the implementation of the various features generally isn't very complex (and where it is complex, such as the physics system, it shouldn't be because such complexity should have been delegated to an external library). There are a lot of "moving parts" which operate simultaneously, but if you isolate and dissect them then you'll find that they all obey fairly straightforward rules (such as inverse kinematics). The advantage of Flash isn't its power or scripting flexibility. It actually handles set operations (and timed/recurring operations) pretty poorly. Its chief advantage is its lack of code security/integrity measures. This makes it possible for modders to dramatically alter the behavior of the game (viz: animtools) or add new features ... at runtime.

To achieve the same results in a typical 3d sex-sim, you'd need a binary patch or runtime memory intrusion. Look at how much hassle people needed to undergo in order to create mods for freaking Minecraft.

To include such openness and moddability in a brand-new game, you'd need to either anticipate every possible change (so that modding is little more than editing a bunch of Config files) or you'd need to expose a huge API (which slows development and hinders your ability to patch the game).

 

[DKOC]

Having played The Klub 17 games and several Illusion games, most of them don't do "cum physics" in 3D, and instead apply a "cum" static texture instead. My "plan" was to have cum produced at runtime via metaballs / metapolys (as it doesn't have to be ball-shaped to work), and have it so that it would have physics applied to it for a brief period of time and then stop (much like how Dark Souls 2 did it, where at death the body would ragdoll, but once it hits the ground, it becomes rigid and unaffected by physics anymore). The reason for stopping is of course having to calculate physics on all those excess polygons every frame would eat up calculations by a lot.

Side point = Could physics be applied to the strands in SDT for a short period of time, and then stop applying physics to them (ie they stay where they land and don't move from there)? If it could be done, it could dramatically reduce computational costs for the heavy framerate eater in SDT, strand physics, as the more strands active the faster framerate tanks.

Question = What 3D game caters specifically for the "tentacle" fetish? I've tried searching for such a thing for many years and never found one. I know of that dynamic position (make your own position) furry 3D game (which I'm not into; but its still an interesting technological marvel), but not heard of any tentacle specific 3D game. I know there is two 3D "movie/game-type" things, set up in a similar manner to G4E is (where you can choose scenes but otherwise have no real control over the scene itself). Could you name any game that comes to mind that fulfills the tentacle specific fetish?

I didn't realize that SDT wasn't as complicated as it currently appears; I assumed making each 2D layer move all at the same time, while avoiding clipping and making movement look fluid would be a huge chore.

I'm assuming a binary patch would be something like an ENB and a runtime memory intrusion would be something like a Skyrim Script Extender (SKSE)? How does it work then for something like the Elder Scrolls games where modding is supported; I know that some modders for those games do still use binary patches or runtime memory intrusion. So in Elder Scrolls games it loads new assets into the game world or overwrites existing assets; is that achieved also by binary patches or runtime memory intrusion, or something else entirely?

Aren't most of those modding APIs released after a game's development has been completed, to avoid a situation where patching becomes a chore? I know that for Rimworld, a modding API has been released and it definitely does slow down game development, BUT, it doesn't seem to slow down patching; it just breaks any mod that operated on the previous patch.

 

[stuntcock]

Having played The Klub 17 games and several Illusion games, most of them don't do "cum physics" in 3D

True, but I doubt that it would be enough of a "selling point" on its own. If I've spent years painstakingly re-creating the entire cast of my favorite anime show as Illusion characters, then I'll need a strong incentive to jump ship.

Side point = Could physics be applied to the strands in SDT for a short period of time, and then stop applying physics to them (ie they stay where they land and don't move from there)?

Yes.

If it could be done, it could dramatically reduce computational costs for the heavy framerate eater in SDT

No, it wouldn't. The strand physics system isn't a framerate eater.

as the more strands active the faster framerate tanks.

The more strands visible the faster framerate tanks. The physics calculations carry a negligible cost. Collision detection in 2d is absurdly cheap, and SDT does a half-ass job of it anyways. Only a few layers are "collide-able"; semen strands can attach to the torso and face but not to the hands (for example) and clothing is ignored.

Each strand is effectively another layer of graphics on top of the scene, and those things add up quickly. Which brings us back to your earlier suggestions about Stage3d composition, ScaleForm acceleration, etc...

Question = What 3D game caters specifically for the "tentacle" fetish?

It was something Japanese; it's difficult to remember details when you can't even figure out the UI well enough to control the camera (let alone change scenes and positions). I'll PM you if anything useful comes to mind.

I assumed making each 2D layer move all at the same time, while avoiding clipping and making movement look fluid would be a huge chore.

The system itself is fairly "lazy", which puts more of a workload on modders (or "constrains their creativity", to put it another way). There's no blending between adjacent bodyparts, so whenever two parts meet (e.g. elbow), one or both of them must end with a semi-circular hinge. Therefore rotation will never leave a gap between adjacent bodyparts (and you don't get the weird anatomical distortions of SFM) ... but you can't model atypical stuff (like big drooping sleeves) unless you abandon the template system and move to physics-based clothing.

Other anatomical details are simply omitted. We never see anything between the girl's legs, so that stuff was skipped. She doesn't just lack genitalia; most of her pelvis is missing. This leads to problems when you're trying to create fancy underwear and discover that the game normally draws panties as a single layer which rests on top of the entire body. If you want a thong to actually fit between the butt cheeks, then you need to hack the game.

I'm assuming a binary patch would be something like an ENB and a runtime memory intrusion would be something like a Skyrim Script Extender (SKSE)?

Binary patch is literally "open the EXE file in a hex editor, change the value at address xxxx to yyyy". Or you run a script which does the same thing. Obviously this approach isn't compatible with heavy modding, because the various patches will overwrite each other or turn the entire file into gibberish. It also depends on a specific version of the EXE file; the technique will fail if the user has an out-of-date copy. It's often used by pirate groups when only a single alteration is needed (e.g. disabling a DRM check).

ENB isn't exactly the same thing. It's an intermediary which intercepts d3d function calls and thus changes the game's visual output, but (AFAIK) it leaves the game files intact.

Memory intrusion also leaves the game files intact; a companion program runs alongside the game. The program's authors have mapped out the game's memory allocation and can manipulate specific values in realtime to achieve changes in the game simulation. Cheating is an obvious use-case, but there are more elaborate example. For example: the program might broadcast information about the game-state to a remote client, and use the remote client's input to adjust the position or actions of an NPC character -- effectively changing a singleplayer game into a multiplayer game. You could also reformat game data into a spreadsheet view for player convenience (because the actual in-game UI presents information poorly). Or you might reprogram Super Mario into Pong by pressing gamepad buttons in the correct sequence. Memory manipulation is usually more "robust" than binary patching, since a game's memory structure doesn't change radically; modders usually just need to find the new offsets after each patch (although they'll need to work harder after a major expansion pack).

I think that SKSE is a mixed example. It appears to do some code injection as well as memory manipulation.

So in Elder Scrolls games it loads new assets into the game world or overwrites existing assets; is that achieved also by binary patches or runtime memory intrusion, or something else entirely?

Most of it is achieved by the Gamebryo system itself AFAIK. Bethesda provided an inherently moddable game, but they didn't go far enough. For example: AI behavior was configurable, but only by tweaking a bunch of pre-established numeric parameters. If you wanted to write entire custom AI scripts then you'd need to use SKSE. I think. It's been a while since I've done anything with Skyrim modding.

Aren't most of those modding APIs released after a game's development has been completed, to avoid a situation where patching becomes a chore?

The API might not see a public release until late in development, but the modding hooks should definitely be included in the ongoing development because it will be obscenely difficult to add them later on. Which means that the team needs to consider how much information should be exposed, how it should be protected, whether it should be editable (are we concerned about cheating? do we have online leaderboards? would a player's ability to cheat discourage them from buying gold via microtransactions? would a player's ability to replace textures allow them to use prestige skins/costumes without actually buying them via microtransactions?), and so on. These deliberations tend to slow down development, and once the decisions are made they will limit the dev team's freedom of action.

If you're trying to attract a modding crowd for your game, then it would be a good idea to include some modding features in the initial versions. The early-adopter crowd tends to be technically literate and highly motivated; they're the sort of folks who will spearhead modding efforts. If you tell them "nope you can't actually edit anything, just play the demo for now and maybe check back in six months" then that's simply not enough to sustain their interest. They'll probably move on and forget about your game long before it's released. Which sucks, because those guys will tend to show off their WIP modding projects on forums (which gets people hyped about your game and spreads word-of-mouth).

@Konashion provided mod support long before his game was mature. He involved modders in his work and took their suggestions seriously. His game has retained a modding group years after the cessation of actual development.

Of course, you could always try to exploit the situation. Withhold your public API until the actual game release, but allow beta API access to high-level Patreon supporters. Use the modders as beta-tester guinea pigs, and let them pay you for the privilege. On launch day, your game will already have a bunch of working mods available for download. You'll probably burn a lot of goodwill among hardcore fans, but if your game is good enough then maybe they'll forgive you.

 

[DKOC]

Most of the selling point would be that the "sex" stuff would be packaged into a "romance/rape" system as one of a variety of different systems in an Open World RPG. The sex wouldn't be able to "sell" the product on it's own; however, most Open World RPGs do not have visual sex in them (ie you can engage in sex in Dragon Age, Fallout, or Skyrim, but it fades to a black screen). As for the prototype with just the sex in it, well, if no one was interested in it, then development for it would cease the moment all of the features were properly tested for the Open World game. If there was interest in it, then I'd likely work with modders to create an API. If there was no interest though, then it would be treated like a throwaway prototype. The decision of if there is sufficient interest would be decided during development of the prototype, which as I said before is at least 2+ years from now anyway; its on the back burner, while I focus on more pressing issues, namely getting my RTS setup and working.

If it is a visual problem, that is eating the framerate up, rather than the physics, then some suggestions to that:
1) In some games, developers are able to choose to delay some visual effects to render on certain frames, rather than render every frame. Could certain visual elements be set to render every 2nd frame instead of every frame?
2) What causes the major bottlenecks? CPU or RAM? If it is CPU, can you force the affinity to a different core, so that the game is managed on its own separate core rather than fight for CPU cycles when run on the 1st core with everything else? If it is RAM, do you know if it can be set to utilize these resources = Virtual RAM, EMS or XMS?
3) Can visual quality be reduced for JUST the strands? I know that you can adjust the visual quality of everything with a single button in Options, but what about reducing just the visual quality for strands; fewer pixels is fewer resources required.
4) Can it be set to cause only the topmost layer of a strand to be rendered, and thus any strands underneath another are culled? Thus if you have like 18 strands of cum that have basically layered ontop of eachother, could only say the top 8 strands could be rendered while the 10 others below them are culled?
5) Can the color value (doubt that is the right term) be changed for specific visual elements that aren't needed as much? So convert a 32 bit color to 16 bit color?
6) Can a system be implemented that slowly degrades visual elements as more elements become present, and then reverts that visual degradation as visual elements disappear? So, in like a AAA game where you have High graphics settings, if more units got on the field, and the CPU couldn't handle it, it might reduce the graphics down to Medium to help handle the load. So, could it be set to reduce visual quality from high to lower as more things appears? Now, it is true that this might be highly undesirable for most players, but could it be made to selectively reduce certain things of visual quality first before affecting everything else? (ie Visual Quality is reduced to Medium for Strands when 10 strands present, and everything else set to Medium when 15 strands present, etc)
7) Noticed this while surfing a separate forum = Legend of Krystal Forums • View topic - Flash "direct" rendering and future improvements ; It mentions a "Direct" rendering that enables the GPU to render some stuff for Flash. Do you think this could be enabled for SDT?

Thanks for clarifying the difference between Binary Patches and Memory Intrusion.

Good point on making a decision when to release an API. I'll have to keep that in mind.

The issue with getting a modding crowd involved too early though is it may result in modder burnout by the time the product is released, if the modder must repair their mod with every patch released. This is something I've noticed with Rimworld, where each patch forces modders to basically repair their mod or rebuild it entirely. I've seen many great modders come and go, well before release of the game due to this, and in some ways this will hurt Rimworld's launch. So, how would one get around this problem? Most of Konashion's work didn't break most mods (it did for the Loader), but I think it also limited the amount of work he could do to patch things as well.

Considering the game industry is going down the shit hole, and all the same conditions that caused the last game industry crash is present RIGHT NOW in the game industry, doing something like that could screw a developer over in the long run. I understand why some do it, but I personally would rather have it as a public API release, to avoid such an outcome of possible loss of loyalty by others. I might decide on a "closed beta" where those involved are picked to help work out bugs in the system before doing an "open beta", but I wouldn't force people to pay to get into the "closed beta". Those are my thoughts at least.

 

[stuntcock]

1) In some games, developers are able to choose to delay some visual effects to render on certain frames, rather than render every frame. Could certain visual elements be set to render every 2nd frame instead of every frame?

Yes and no. What we can do is "reduce" an element to a bitmap; Flash can then cache it and render it much more quickly. We could then restore the vectors after <n> frames, display them, reduce it back to bitmap, etc... It would turn into a form of jerky stop-motion animation - in which the strands themselves would exhibit much lower FPS than the rest of the scene. But at least the game would remain responsive to user input.

Unfortunately, it won't work because bitmaps can't use partial transparency. The strands would turn into solid white lines. When this visual factor is combined with the weird jerky animation, it would almost certainly become unacceptable to users.

2) What causes the major bottlenecks? CPU or RAM? If it is CPU, can you force the affinity to a different core, so that the game is managed on its own separate core rather than fight for CPU cycles when run on the 1st core with everything else? If it is RAM, do you know if it can be set to utilize these resources = Virtual RAM, EMS or XMS?

It's CPU. Users are free to adjust core affinity, but it won't do much good.

3) Can visual quality be reduced for JUST the strands? I know that you can adjust the visual quality of everything with a single button in Options, but what about reducing just the visual quality for strands; fewer pixels is fewer resources required.

It's a stage-level option.

4) Can it be set to cause only the topmost layer of a strand to be rendered, and thus any strands underneath another are culled? Thus if you have like 18 strands of cum that have basically layered ontop of eachother, could only say the top 8 strands could be rendered while the 10 others below them are culled?

It's rare for strands to overlap exactly. More commonly, you'll end up with a "cobweb" pattern in which there is some overlap and some independence. If we cull something, then part of the cobweb will suddenly vanish in front of the user's eyes.

The broader idea ("cull the lower strands when too many appear on screen") is already fulfilled by @sby's strandLimitV3 mod.

5) Can the color value (doubt that is the right term) be changed for specific visual elements that aren't needed as much? So convert a 32 bit color to 16 bit color?

It's possible to reduce the color depth of a bitmap in AS3, but I think that it would usually be done for artistic reasons rather than performance reasons.

The problem is composition. When we add a lot of partially-overlapping, partially-transparent graphics layers to the stage, Flash needs to do a lot of work on each frame in order to assemble the final picture. Reducing the color depth of the vector graphics probably wouldn't help much (also: I don't know offhand how to do it so I can't run a quick test).

6) Can a system be implemented that slowly degrades visual elements as more elements become present, and then reverts that visual degradation as visual elements disappear? So, in like a AAA game where you have High graphics settings, if more units got on the field, and the CPU couldn't handle it, it might reduce the graphics down to Medium to help handle the load. So, could it be set to reduce visual quality from high to lower as more things appears? Now, it is true that this might be highly undesirable for most players, but could it be made to selectively reduce certain things of visual quality first before affecting everything else? (ie Visual Quality is reduced to Medium for Strands when 10 strands present, and everything else set to Medium when 15 strands present, etc)

Yes, this is possible. The sudden change in visual quality is quite noticeable, though. It's assumed that anyone who suffers from inconsistent FPS would take precautionary measures -- such as reducing the graphics to Medium or shrinking the game window. The experience would be slightly worse than if the game bumped itself up to High during the quiet moments, but at least it would be consistent.

I don't even use High graphics except when taking screenshots; my computer can't handle it.

7) Noticed this while surfing a separate forum = Legend of Krystal Forums • View topic - Flash "direct" rendering and future improvements ; It mentions a "Direct" rendering that enables the GPU to render some stuff for Flash. Do you think this could be enabled for SDT?

It is enabled. Unfortunately, this loops back to the earlier suggestion about Stage3D. If we rewrite some of the game code and reorganize the graphics, then we could effectively delegate much of the work to the GPU. The GPU is a fairly specialized piece of equipment, and (at the moment) it simply doesn't "understand" any of the tasks involved in rendering SDT.

One major "opportunity" is video rendering. If you replaced the SDT background image with a full video file, then normally the CPU would struggle -- because video decompression is somewhat costly, and the CPU is already overburdened. But because the GPU acceleration is on, the GPU will assist in this task.

The GPU would also assist with any 3d elements that we decided to place on the stage. The most obvious example is the "props" used by @sby's animtools mod. Unfortunately, the example doesn't work because the props aren't actually 3d objects; they're just SVG files which are drawn with a bit of perspective.

The issue with getting a modding crowd involved too early though is it may result in modder burnout by the time the product is released, if the modder must repair their mod with every patch released. This is something I've noticed with Rimworld, where each patch forces modders to basically repair their mod or rebuild it entirely.

Yeah, that's a valid point. It depends on the "discipline" of the dev team. If they consider their API to be a rock-solid contract, then modders would simply need to recompile after each new release. If the API details change often (e.g. because the team published it without a lot of internal review), then modders will need to do a lot of work, and some project may be suddenly orphaned because the necessary API methods are cut off.

So, how would one get around this problem?

Talk to your modders. Keep up with the modding scene. Ensure that the mods are in-line with your long-term vision of the game. If they aren't, then negotiate a compromise - change the API to block the unwanted behaviour, but explain why you're doing so and be prepared to offer alternatives.

For example: Guild Wars 2 didn't want people to install lots of UI customization and overlays, because they felt that heavy use of such mods (in WoW) encouraged a playstyle which differed from what they intended to deliver. So they installed restrictive client-side anti-cheat software which prevented almost any modifications (including harmless stuff like nude mods, FOV tweaks, colorblindness tweaks, etc).

On the other hand, EvE Online exposes a huge amount of data via its API. Much of it isn't accessible through the actual game client, so people have written out-of-game tools to view and process it. A minor example is that players can install hidden "siphons" to steal resources from opponents. The developers originally intended that player would need to carefully patrol their space in order to guard against theft. But the patrols were incredibly boring, and players discovered that the could find siphons by reviewing the API data. So they stopped patrolling, and instead simply formed a strike-force whenever the API check showed an active siphon. After a while, players stopped deploying the siphons because they would always be destroyed before stealing anything worthwhile. The developers could have modified the API to hide the information, but this would have annoyed some modders (who had written the API-parsing scripts) and it would have forced players to resume patrols (which were very boring and unpopular). So instead they just accepted the result as part of the metagame.

 

[DKOC]

So, in a nutshell as far as graphical or code optimizations goes, its basically a situation of SOL (EDIT: SOL stands for shit out of luck, which means something is not likely to happen) as far as optimizing the flash version of SDT. The only way optimizations could truly be possible is if it was ported to an actual game engine or Adobe improved flash, neither of which are likely to occur anytime soon.

Good point on the API. I'll have to think about that in greater detail later.

Good point on talking to the modders and keeping them in the loop.

As far as EvE Online goes, doesn't that follow similar Dev Team logic that Bethesaida uses; ie release the game and let the modders fix our game's problems, rather that we fix it? Or am I misunderstanding something here. It seems like by having a lot of their API available allows modders to fix various issues with the game and the development team doesn't prevent them from doing so and don't touch their modded additions or subtractions from the game and allowing it to be part of the metagame instead. Thoughts?

 

[stuntcock]

As far as EvE Online goes, doesn't that follow similar Dev Team logic that Bethesaida uses; ie release the game and let the modders fix our game's problems, rather that we fix it? Or am I misunderstanding something here.

You're correct. Ideally, the dev team would use the modders as a "playground" or "laboratory" - let them tinker, capture the neat/useful ideas, then re-incorporate them into the actual game.

Unfortunately, the EVE dev team tends to move much more slowly than the modders (because they're encumbered by budget limits, office politics, marketing priorities, etc). By the time that they officially take notice of a cool mod, it's often mature enough that the dev team could not substantially improve upon it. All that they could do would be -- at the cost of thousands of hours of dev time -- to reimplement the whole thing with new code and integrate it into the game client (which would then necessitate thousands more hours of regression testing). There's no up-front guarantee that the official version of a tool would even be better than the existing fanmade version.

So instead the dev team tends to focus on tasks that are impossible for modders (such as expanding the game map, optimizing the netcode, or inventing new kinds of spaceships) while the players write their own tools and spreadsheets to organize supply routes, assign leadership roles, manage communications during large-scale battles, root out spies within their ranks, etc...

It seems like by having a lot of their API available allows modders to fix various issues with the game and the development team doesn't prevent them from doing so and don't touch their modded additions or subtractions from the game and allowing it to be part of the metagame instead. Thoughts?

Yes, I'd say that that's correct also. If the EVE developers had taken the Guild Wars 2 approach ("no mods ever!") then their game would probably have died years ago. Modders, guild leaders, third-party fansites, etc... have built up a community and metagame which keeps players interested. If you strip all of that stuff away then the game simply isn't interesting enough to deserve a monthly subscription fee.

We can draw a rough parallel here to SDT. The core mechanics are solid, but if the game was un-moddable then it's doubtful that anyone would still be playing it. Including "moddability" as a core feature can help to sustain a game. You can take this as a good thing (in that it allows niche games to survive) or a bad thing (in that it allows publishers to release unfinished crap and let someone else fix it) but it's worth considering when you plan out your own game.