RPG MAKER MV OFFICIAL PAGE

[Hudell]

Honestly, this is a useless discussion. Once the new maker is out, we will make a script to use 32x32 tiles. Don't worry about that, people.

 

[JosephSeraph]

Even if you make a 400x400 character they still occupy one 32x32 tile.

Sure, you can make characters taller or shorter than 32x32, you can make them go a little wider... but using the default rpg maker engine, a character = 1 tile.

That's 16x16 for 2k/3 and 32x32 for XP/VX/VXA.

 

[SamJones]

Even if you make a 400x400 character they still occupy one 32x32 tile.

Sure, you can make characters taller or shorter than 32x32, you can make them go a little wider... but using the default rpg maker engine, a character = 1 tile.

That's 16x16 for 2k/3 and 32x32 for XP/VX/VXA.

You might want to elaborate that for easier understanding.

It is not how large the character looks on the screen that's the problem if I understand you correctly, it is the interaction with the game logic that is the issue here. For determining collisions, interacting with events, passability etc. the character is tracked solely by the tile it occupies. The SINGLE TILE it occupies in the game logic. Whether the sprite representing it on the screen, fits into it or spreads over twenty tiles in either direction.

 

[Shaz]

This is not really the thread to discuss that.

 

[MysteryMan23]

Anyways, I'm glad for one thing: they seem to have finally added hardware acceleration. At least, presumably, given the whole thing about needing OpenGL. I wonder if that also means we can use shaders? Hm...that would be useful, certainly.

 

[Rukiri]

Anyways, I'm glad for one thing: they seem to have finally added hardware acceleration. At least, presumably, given the whole thing about needing OpenGL. I wonder if that also means we can use shaders? Hm...that would be useful, certainly.

You can use openGL and it still can be software rendered, a good example of this is mid-late 90s PC games.  They were using Direct X "both software and hardware rendered", so the engine could still hugely be software rendered which would suck...   I remember when you tried to do a major battle system with 2k/3 and it'd just slow down "runs fine today thanks to better hardware". 

 

[Ramiro]

You can use openGL and it still can be software rendered, a good example of this is mid-late 90s PC games.  They were using Direct X "both software and hardware rendered", so the engine could still hugely be software rendered which would suck...   I remember when you tried to do a major battle system with 2k/3 and it'd just slow down "runs fine today thanks to better hardware". 

This only happens if you dont have an actual video card without openGL support, yes the software will be emulated.

You cannot decide wich video card you will use by default, and openGL is rendered "how it seems the best way"

This will be acelerated, even in the html version...

 

[Rukiri]

I want actual proof, and yes you can force software openGL rendering, I've done it with sfml and sdl ages ago.   

RPG Maker has always been software rendered even in the year 2011 "when accelerated 3D and 2D cards shouldn't be an issue" 

 

[Shaz]

You won't get actual proof until someone who's already using it comes and says so (which they won't, because they're all under NDA), or until it's announced on one of the sites somewhere, or until it's released. Don't expect proof from anyone in this thread

 

[Tsukihime]

I wonder how the browser games will handle data transferring when assets are loaded.


It would be terrible if


1. You need the RTP installed, or


2. The entire RTP + other assets are downloaded before you can start playing

 

[GrandmaDeb]

I wonder how the browser games will handle data transferring when assets are loaded.


It would be terrible if


1. You need the RTP installed, or


2. The entire RTP + other assets are downloaded before you can start playing

I thought I read that the RTP would no longer be a separate install. I mean, when you download a phone app, you do not use a separate data install for the graphics, so it makes sense.


/me looks for that information...


*************************


edit


*************************


ahh well it says


"RTP is now integrated in the engine to save the users trouble."


so "users" probably means game makers, not game players, so I do not know anything.


(no shock.)

 

[JosephSeraph]

I think it probably compiles intelligently instead of dumping everything into the exe like rm's always done

 

[Mister.Right]

I wonder how the browser games will handle data transferring when assets are loaded.

It would be terrible if

1. You need the RTP installed, or

2. The entire RTP + other assets are downloaded before you can start playing

JSON and $.ajax  I think. That is how Javascript handles data. There are already many HTML5,JS game engines out there capable do better than that. Also many APIs to handle render, physic...etc are open source. You expect to write less code than previous VX thus reduce time to develop plug-in.

 

[orochii]

Legend of Mana in 816x624

Legend of Mana is beautiful no matter what technical errors the developer commits <3.

You might want to elaborate that for easier understanding.

It is not how large the character looks on the screen that's the problem if I understand you correctly, it is the interaction with the game logic that is the issue here. For determining collisions, interacting with events, passability etc. the character is tracked solely by the tile it occupies. The SINGLE TILE it occupies in the game logic. Whether the sprite representing it on the screen, fits into it or spreads over twenty tiles in either direction.

Just wanted to say that you will probably be able to change how collisions work by plugins/script.

Or you can throw some extra invisible blocking tiles so your bigger characters don't appear as trespassing walls so much.

Maaaaaaaan. I wish for a trial. You NDA'd people sure are happy. How jealous am I... Sons of submariners.

 

[Rukiri]

Legend of Mana is beautiful no matter what technical errors the developer commits <3.

Yea it is!  

Controllable tile size and resolution should be pretty easy this time around, which is good.  

 

[Killuki Zaoldyeck]

Mmmm... I guess that would be possible do a script that detects the non-transparent areas of the PNG images and automatically creates the collision areas ignoring the transparencies, that would save a lot of time to everyone that uses a pixel movement system, and would be even more precise.

As far I know, such script doesn't exist yet. If that's so, then, why no one has made a collision system which ignore the transparency of the images and uses the colors as collision areas? Such script would be absolutely perfect for any pixel movement system.

The only problem that can cause such script is for example when the character uses a huge cape bigger than it's body which shouldn't count as collision area, or when you want to do possible walk below a big monster's wings (for example, a Dragon), but for these special exceptions, such amazing script would have the option to define manually the collision areas, or for less complications, you can compose for example the Dragon using two charsets, being the first one the body being 100% collisionable, and the second one the wings which is defined inside the script/usingcomments/nameprefix/sufix/anything as an exception (doesn't have any collision area).

I know that scripting is not easy (this plus my bad memory is the reason why I don't learn scripting), but hard doesn't means impossible, there are a lot of amazing scripts like light effects (khas, which is being even more improved), screen effects (zeus), and more things which in the past could be considered as impossible or unfeasible. If someone is motivated enough to challenge himself/herself, and considers that posses enough scripting knowledge, will do such collision system for the new or even older RPG Makers.

EDIT: I had the collision system idea right now.

EDIT2: Just to clarify, I meant that maybe there's not a collision script like the one I thought right now, I know that there's already some collision system, but as far I know there isn't any script like what I'm saying.

 

[Hudell]

Mmmm... I guess that would be possible do a script that detects the non-transparent areas of the PNG images and automatically creates the collision areas ignoring the transparencies, that would save a lot of time to everyone that uses a pixel movement system, and would be even more precise.

As far I know, such script doesn't exist yet. If that's so, then, why no one has made a collision system which ignore the transparency of the images and uses the colors as collision areas? Such script would be absolutely perfect for any pixel movement system.

The only problem that can cause such script is for example when the character uses a huge cape bigger than it's body which shouldn't count as collision area, or when you want to do possible walk below a big monster's wings (for example, a Dragon), but for these special exceptions, such amazing script would have the option to define manually the collision areas, or for less complications, you can compose for example the Dragon using two charsets, being the first one the body being 100% collisionable, and the second one the wings which is defined inside the script/usingcomments/nameprefix/sufix/anything as an exception (doesn't have any collision area).

I know that scripting is not easy (this plus my bad memory is the reason why I don't learn scripting), but hard doesn't means impossible, there are a lot of amazing scripts like light effects (khas, which is being even more improved), screen effects (zeus), and more things which in the past could be considered as impossible or unfeasible. If someone is motivated enough to challenge himself/herself, and considers that posses enough scripting knowledge, will do such collision system for the new or even older RPG Makers.

EDIT: I had the collision system idea right now.

I think tsukihime has an script that is kind of like that. Someone talked about it on a thread and I was waiting for a reply there to make sure it was compatible with my movement script, but I guess that thread is long gone now.

 

[♥SOURCE♥]

As far I know, such script doesn't exist yet. If that's so, then, why no one has made a collision system which ignore the transparency of the images and uses the colors as collision areas? Such script would be absolutely perfect for any pixel movement system.

1. Most community members don't have the knowledge to do it.
2. It's a terrible idea.

If someone offers you that feature, run as fast as possible in the opposite direction.

 

[Killuki Zaoldyeck]

1. Most community members don't have the knowledge to do it.
2. It's a terrible idea.

If someone offers you that feature, run as fast as possible in the opposite direction.

Why? And I hope that my post won't heavely derail the topic.

 

[Shaz]

It would lag like crazy.


Maybe that's why none of the scripters have done it yet - they know what the effect will be.