Can automapping be really as good as parallax mapping?

[Sharm]

It's a little off-topic, but I could never understand how this engine could have perforamance problems?

Aren't you saying right here that you don't think that MV should ever have performance problems?  I don't know how to read this any other way, I'd love to know what you really meant.


I didn't really answer the main question, did I?  I think tile mapping can be just as good or better than parallax for multiple reasons, but it depends a lot on the mapper and what's being mapped.  I'm the sort of artists who likes to see how creative I can get with tile placement, being precise, and fiddling with each possibility until I get what I want.  It makes me a great pixel artists and means I prefer tile based mapping.  I can do more with it than I can parallax maps, and it'll look better.  Then there's someone like Celianna who's really great at editing tiles and parallaxes fast.  She does better with parallax maps, feels that working in tiles slows her down and gets in the way, and it's completely true.  My maps can look just almost fabulous as Celianna's, but hers will always look just a little more organic.  My maps, however, will be more efficient.  It would also take me much, much longer to do things Celianna's way and wouldn't look as good because I'm just not that type of mapper.


In the end it really does all come down to performance.  What's more important, great maps that aren't as organic but are much more efficient, or amazing maps that are inefficient but so much more organic?  It also comes down to what type of mapper you've got.  Play to your strengths.

 

[J_C]

Aren't you saying right here that you don't think that MV should ever have performance problems?  I don't know how to read this any other way, I'd love to know what you really meant.

Well, yeah, I think from a technical standpoint, RPGmaker VXAce-MV shouldn't have performance problems on today's machines, because even a lots of parallax events shouldn't tax a CPU like the most CPU intensive AAA games. How does these need so much computing, when there are barely any "moving" parts in this game? And I assume those are even worse on older computers.

 

[Andar]

Well, yeah, I think from a technical standpoint, RPGmaker VXAce-MV shouldn't have performance problems on today's machines, because even a lots of parallax events shouldn't tax a CPU like the most CPU intensive AAA games.

You made a few wrong assumptions here.


A correctly written parallel process has very little impact on lag - the parallels that impact are usually written in a bad way (with bad programming logic) by people who don't understand what parallel process is. A single badly written parallel process can lag even the most powerful machine ever build, and too many users around here have the opinion that parallel processes are a heal-all for development problems. That's why their games lag like hell on even good computers.


However, RM needs more processing power because it's an interpreted engine, not a compiled engine - that is a very important technical difference, and a lot of the top games can only handle the many details because they use compiled engines, not interpreted ones. But compiling also creates rigid limits as to scripting and eventing and it wouldn't be as easy as it is now to change the engine...

 

[J_C]

You made a few wrong assumptions here.


A correctly written parallel process has very little impact on lag - the parallels that impact are usually written in a bad way (with bad programming logic) by people who don't understand what parallel process is. A single badly written parallel process can lag even the most powerful machine ever build, and too many users around here have the opinion that parallel processes are a heal-all for development problems. That's why their games lag like hell on even good computers.


However, RM needs more processing power because it's an interpreted engine, not a compiled engine - that is a very important technical difference, and a lot of the top games can only handle the many details because they use compiled engines, not interpreted ones. But compiling also creates rigid limits as to scripting and eventing and it wouldn't be as easy as it is now to change the engine...

I understand that. I just hope this can be improved a little bit in the future.

 

[Andar]

I understand that. I just hope this can be improved a little bit in the future.

Nope


The only possible solution is to teach people how to use parallels, the rest can't be changed for a lot of reasons. Going to a compiled engine would cause too many other problems, they have good reasons for staying at an interpreted engine.

 

[J_C]

Alright, alright.

 

[Sharm]

I think I get what you're saying now, you're saying with today's machines and with such low fidelity games with such simple requirements there should never be a need to worry about things like file size, processing power, and so on, because we're not the type of engine that pushes boundaries, we should fit so well within those boundaries that we never see them.


The thing is though, that's why I was saying comparing us to a AAA game is like comparing apples to oranges.  RPG's are closer to the casual market these days, which is why we're pushing for mobile compatibility instead of 3D rendering.  A graphically intense low story game is going to tax the system in different ways than a graphically simple high text volume game.  That doesn't mean they don't both tax the system, they just do it in different ways because the games are different.


Another thing I'd like to point out is that even if you're making flappy bird for use on the latest alienware machine that doesn't mean you don't have to worry about what processing you're using.  It won't be an issue unless you royally screw up the code, but being aware of your resources and making conscious choices about them instead of just doing whatever you want because you can, that's good design.  It won't affect the performance, sure, but it will affect the quality of your game.


That's why your question is a good one, it's good to compare these options and choose what's best for your game.  Sometimes that means you're aiming for higher end machines or aren't hosting online or other things, and that's fine.  The important thing is to go for that because it's a choice, not to just make a game and suddenly realize after you've made it that half your intended demographic can't play your game because of assumptions.

 

[Demiqas]

No - you're forgetting that with parallax mapping, you still need to set the passability by tile in the regular editor. That is an additional step on top of everything that is already handled by regular mapping automatically. And if your parallax mapping is faster than regular mapping, then you're not using all options of parallax mapping (like placing parts off-grid and in multiple layers), because those also take extra time compared to regular mapping.

everything you have said about parallax mapping in this thread is entirely based on your own assumptions. Making your first few maps especially if you have no editing software experience will take you some more time, but once you get used to it you get a lot quicker and more efficient at it. I also have no idea how you come to the conclusion that parallax mapping quickly equals not using it correctly. Again, you become a lot quicker at it with experience.


and if you have designed your map properly, adding passabiliy takes a minute, maybe two tops.