PEPSIOTAKU'S PROFILE

Search

Filter

[RM2K3] game protection

author=Mirak
Wow, that software sounds super useful for other kinds of things.

Like, my game folder usually looks like this and it looks messy and people not used to computers might click something they shouldn't or remove files when they shouldn't and this tool would help greatly.

Yeah you can pretty much pack it any way you want to, ultimately. I don't think dlls are that big of a deal though. With 2k/2k3 games, you basically have like 10 folders with XX number of resources, and hundreds of map files, so it's more for trimming that type of thing down to 1 or 2 files. I'm assuming there's a lot of stuff in that resource folder, so you could basically turn that into a resource.*** file using Enigma.

You could take it a step further and create an installer/shortcut (which would make people bitch even more), and if they break the game somehow by deleting files they're not supposed to, it's kind of on them. So I wouldn't worry about that aspect of it too much.

[RM2K3] game protection

@BluePhoenix: An actual answer to your question... Enigma Virtual Box. MoleBox was probably the one your thinking of, but it's not that reliable. See my post about it here:
https://rpgmaker.net/forums/topics/18566/?post=730825#post730825

My opinion about the matter is that if it's your game that you spend hundreds of hours on, you should be able to protect its resources if you want to. What other people say or want about the matter is kind of irrelevant. If they want to change things or rip resources that badly, let them struggle. :)

+++ DynRPG - The RM2k3 Plugin SDK +++

Nope. Gotta be a renegade and get the unofficial translation. Just do a google search for "rpg maker 2003 rpgadvocate" and it should come up. Doesn't hurt to have the official version too though to show support.

+++ DynRPG - The RM2k3 Plugin SDK +++

author=Corti
So the rpg maker is still drawing onto the screen->canvas but the canvas is shown in OpenGl instead DirectDraw?


Yes. You can hide it with:
ShowWindow(GetParent(RPG::screen->getCanvasHWND()),SW_HIDE);


It's a little hacky, but it works.

+++ DynRPG - The RM2k3 Plugin SDK +++

author=Corti
Nice! Did you create your own openGL rendering for every element of the game?

Right now it's basically one object within the rendering window, and all of the pixels from 2k3 get placed in that object.

I think what you're suggesting would require hooks into RPG::Image that create gl objects for each, but that would break a ton of stuff like effects, brightness and transitions. Ultimately though, that would be a cool thing to pursue because you could layer your own opengl objects into it. It's something I'm considering figuring out in the future, but for right now, I'm just happy to rid myself of DirectDraw. :)

author=AubreyTheBard
Interesting. I wonder if this could be used to create special effects. Make the screen bulge in a particular spot, etc.

More or less, yeah. You'd have to write a pixel shader to do that.

Screenshot Survival 20XX

Pretty sure this is how black holes work...



About/My crazy ramblings here: https://rpgmaker.net/forums/topics/10254/?post=747512#post747512

+++ DynRPG - The RM2k3 Plugin SDK +++

Gentlefolk, I have seen the light... it is very good, full of shaders, and powered by OpenGL.

So this was something I started months ago (like October?) and shelved because I couldn't quite figure it out, as seen here. I had a few goals in mind:
  • Render 2k3 in OpenGL and say goodbye to the aged-so-poorly DirectDraw renderer (which is weirdly slow in Windows 10)
  • Replace the use of AnotherFullscreenMode (it was a bit on the hacky side for my tastes)
  • More or less copy official 2k3, in how it can render in various ways (1x-4x, interpolation, 1:1 scaling vs ignoring aspect ratio, stretch to screen)
  • Bridge it to the simple and powerful SFML library, which is capable of both 2D and 3D objects

I finally revisited it over the weekend, got some help with a couple things, and managed to figure it out and then some...



To describe what's going on here: Each pixel is converted to an SFML-readable format, and added to a flat 2D sprite, which can then be manipulated in numerous ways. SFML makes it pretty easy to add shaders, and the curved CRT monitor look is one of them. There is also no visible speed loss whatsoever. It's absolutely beautiful, although shader speed capabilities might be dependent on how old your video card is. Mine is like 5 years old or so to give you a frame of reference.

Improvements over official 2k3: The window size still alternates between different sizes, but this one can scale up to the desktop resolution. Example: If you have a 1920x1080 screen, it scales up 1x, 2x, 3x, and 4x. If you have a 4k screen, in theory it should be able to scale up to 8x or 9x, but I can't confirm yet (anyone have a 4k monitor that wants to test this for me?). Another feature I added was the ability to take screenshots and save it to a file, because it was stupid easy with SFML. I wanted this feature because this renderer (and official 2k3 for that matter) scales up to the desktop resolution, so even though the game is 320x240, a screenshot taken in fullscreen could be like 1920x1080... not ideal for sharing on forums such as ours. So this screenshot key saves the 320x240 image to a file. While this doesn't capture the pixel shader in use, you can still use the default alt+printscreen to copy the window & contents to the clipboard (including the shader).

Loading shaders is still something I am figuring out. At the moment, I'm hard-coding the shader filenames and parameters, and switching between them with F7, but eventually I think it'll be an @add_shader "crt" type of thing so that people can experiment with their own, and not be limited to the ones I choose. I'm still learning how they work myself, and vertex shader lingo is on my to-do list, but the only purpose they would have right now is to distort the shape of the screen (potentially leading to some really cool effects). For example, in that CRT shader, the pixels are being distorted with a fragment shader, but the surface is still a flat rectangle, and there's that brown crap around the edges because there is no vertex shader being used. If you want to learn about them, search for "GLSL" shaders as that's the language SFML uses.

Here's some of the "keepers" found/ported for GLSL use/experimented with that will be distributed with the plugin (images are using the 4x window size):

Scale2x:

Scale4x:

CRT:

CRT (Curved):

Noir:

Invert (better for effects... I'll figure that out):

Interpolation (not technically a shader, but figured I would throw it in here):



Shaders gone completely wrong, or just the wrong shader for 23k purposes:

An early attempt at trying to get Scale2x to work...

The CRT shader can do some interesting things...

Turn your 2k3 game into the MSPaint spray tool!

A blur filter... hrmmm this might be useful at some point, but for now it's just silly.

The same blur filter... but more extreme!



The scope of this project is another thing I'm thinking about. With this, you could basically implement the steam overlay or I could turn my gamejolt plugin into a similar overlay, which could be rendered on a separate drawable object from 2k3. SFML also has a ton of input stuff that one could mess with, so I could integrate my xbox plugin into it. Basically as much future-proofing that I can think of. :)

The only downside I guess right now that is that since the entire 2k3 screen is rendered to a single surface, it'll be hard to place objects between existing 2k3 objects. That's a project for another day. :)

As a side note, there is a small bug with the RPG::screen->canvas->convert16To24Bit function that will be fixed in the next DynRPG iteration.

+++ DynRPG - The RM2k3 Plugin SDK +++

I haven't heard from bugmenot since like... October maybe? I can't seem to reproduce that issue though. It never jumps back up to the first entry for me... Is it a bug with one of your patches or plugins? If you can confirm a patch is doing that, you could try to reach out to him via multimediaxis or something.

+++ DynRPG - The RM2k3 Plugin SDK +++

Anything window-related is experimental right now because each one has its own little nuances. You'd need to use some built-in functions related to targeting in order to get it to do what you want. I have the addresses for them, but not the parameters themselves (which could be anything). I'm not brave enough to mess with them:

SystemGraphic 
489F1C(2k3) <>DrawBattleCursor(Target)

BattleScene
495214(2k3) <>TargetWindow
495284(2k3) <>UpdateTargetList
4952FC(2k3) <>DrawTargetWindow
4953E4(2k3) <>TargetList
49571C(2k3) <>CreatePartyWindow
4953EC(2k3) <>EnemyStatusInfo
495420(2k3) <>GetEnemyConditionInfo
4954B8(2k3) <>CloseTargetWindow
..
498044(2k3) <>TargetWindowNavigation
498164(2k3) <>PartyTargetWindow
49824C(2k3) <>ChooseSkillTarget
498328(2k3) <>SkillWindowNavigation
4984BC(2k3) <>ChooseItemTarget
498598(2k3) <>ItemWindowNavigation
...
49A618(2k3) <>CheckTarget

Monster
4BDD5C(2k3) <>CheckValidTarget

Action (Hero)
4C0688(2k3) <>CheckValidTarget

Just look for "asm volatile" in the DynRPG sources files for various examples. Each function is going to be different though... so you might be SOL, but I can give you some pointers. Any time you see "this" in the functions, it's referring to the object being pointed to (in "image->drawString", "this" would be referring to "image"). In your own functions, you can avoid using this by just referencing the objects directly. For instance:

void RPG::Inventory::addItem(int id, int amount) { 
asm volatile("call *%%esi"
: "=a" (RPG::_eax), "=c" (RPG::_ecx), "=d" (RPG::_edx)
: "S" (0x4A620C), "a" (this), "c" (amount), "d" (id)
: "cc", "memory");
}

would become:

void addItem(RPG::Inventory *inventory, int id, int amount) { 
asm volatile("call *%%esi"
: "=a" (RPG::_eax), "=c" (RPG::_ecx), "=d" (RPG::_edx)
: "S" (0x4A620C), "a" (inventory), "c" (amount), "d" (id)
: "cc", "memory");
}

Info about inline assembly here that might help you out:
http://wiki.osdev.org/Inline_Assembly

At a certain point, building a new battle system, assign it a new scene, then redirecting RPG::SCENE_BATTLE to the new one might be easier than trying to make this battle system do stuff it wasn't designed to do... -_-

+++ DynRPG - The RM2k3 Plugin SDK +++

author=JohnLeagsdurg
No plans to make DynRPG compatible for the steam versions yet?

That's up to Cherry unfortunately since he works on the official steam version, and he's bound to what Enterbrain/Kadokawa will allow him to do. DynRPG is partially compiled, and I don't have the original source for the part that is compiled (all the linkage and functions from version 0.20 and prior, the patcher and the addresses to patch)... and I have no desire to learn the assembly/reverse engineering knowledge to do that stuff. I have a game that I want to finish some day :-/

I was able to make updates because bugmenot supplied me with the pointers to the 2k3 classes, while I worked on interpreting it into .h files for c++ use, as well as supplying me with a list of built-in functions that I can add with some usually minor guesswork.