Full Games List
Featured Games
New Games
Reviews
Media
Images
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
Tutorials
Articles
Scripts
Utilities / Plugins
Resources
Engines
Engine Bulletins
What is Makerscore?
Past Events
Achievements
Misaos
Forums
Post History
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
DO YOU THINK ENTERBRAIN HAS ANY PLANS TO RELEASE A 3D PC RPG MAKER
Posts
GreatRedSpirit
View playlists
Closeauthor=JosephSeraph
you know Castlevania: Symphony of the night is actually 3d right
Yes? A huge number of games made in the last two decades run on a 3d API like for example DirectX (which hasn't had 2d rendering, DirectDraw, since before DX9). It's not difficult to render 3d elements in 2d and you get all kinds of horsepower advantages out of it. I still wouldn't trust Enterbrain to not shit the bed with some part of a new 3d maker.
author=GreatRedSpiritauthor=JosephSeraphYes? A huge number of games made in the last two decades run on a 3d API like for example DirectX (which hasn't had 2d rendering, DirectDraw, since before DX9). It's not difficult to render 3d elements in 2d and you get all kinds of horsepower advantages out of it. I still wouldn't trust Enterbrain to not shit the bed with some part of a new 3d maker.
you know Castlevania: Symphony of the night is actually 3d right
Can you please elabborate this? I'm interested.
What do you mean direct X hasn't had 2d rendering?
And castlevania: symphony of the night is in 3d? Including the GUIs?
The gist of it is that you can use existing 3d APIs to make a 2d game. Using the 3d API has several advantages such as free scaling and rotation and you apply your 2d assets to a 3d face and apply orthogonal perspective * to make it appear as if it was a 2d game. Plus it's much easier to put 2d in a 3d game than the other way around. This has been the basis for lots of 2d games that use modern game development APIs. The PS1 and N64 took this approach with their hardware, I think the Saturn focused on 2D games though.
DirectDraw was DirectX's old 2d rendering API. It was replaced in DX8 with a more unified version of Direct3D to take advantage of working with a 3D api and using current hardware.
* I did do this ages ago as a super rough 2d engine in OpenGL. I can't say what real engines written by people who know what they're doing do, especially modern ones. They are super complex and way out of my league. If somebody here has worked on an engine or knew more about the nitty gritty of modern game APIs they'd probably laugh at my entire post for being wrong on all but superficial levels.
DirectDraw was DirectX's old 2d rendering API. It was replaced in DX8 with a more unified version of Direct3D to take advantage of working with a 3D api and using current hardware.
* I did do this ages ago as a super rough 2d engine in OpenGL. I can't say what real engines written by people who know what they're doing do, especially modern ones. They are super complex and way out of my league. If somebody here has worked on an engine or knew more about the nitty gritty of modern game APIs they'd probably laugh at my entire post for being wrong on all but superficial levels.
author=GreatRedSpirit
The gist of it is that you can use existing 3d APIs to make a 2d game. Using the 3d API has several advantages such as free scaling and rotation and you apply your 2d assets to a 3d face and apply orthogonal perspective * to make it appear as if it was a 2d game. Plus it's much easier to put 2d in a 3d game than the other way around. This has been the basis for lots of 2d games that use modern game development APIs. The PS1 and N64 took this approach with their hardware, I think the Saturn focused on 2D games though.
DirectDraw was DirectX's old 2d rendering API. It was replaced in DX8 with a more unified version of Direct3D to take advantage of working with a 3D api and using current hardware.
* I did do this ages ago as a super rough 2d engine in OpenGL. I can't say what real engines written by people who know what they're doing do, especially modern ones. They are super complex and way out of my league. If somebody here has worked on an engine or knew more about the nitty gritty of modern game APIs they'd probably laugh at my entire post for being wrong on all but superficial levels.
Wow, your technical insight got me questioning quite alot.
See, i am actually working my way around this feature because nowadays it's all 3d, and to put 2D GUI/sprite in a 3d game is becoming such a chore to lock its rotation to the camera like a sticker. Sounds counterintuitive, as a friend (another self depreciating noob) concerned.
It's like...having extra z information on your 2d character sprite or window also feels like it'll eat (slightly) more space than working it out cross platform in a separate 2D API and combining the loop afterwards...
We actually thought it's more logical designing the menu loop on a 2d API (maybe RPGMAKER) with different language (not sure why) and then it'll update the info and enter a 3d space during gameplay, again, designed in different extended language. It seems more efficient to me and seemingly resemble classic PSX /N64 games...but now that you mention it's all done in 3d, i am now doubting my own calculation.
Well if you can't laugh it out abit, developing a game in a teamwork wouldn't last v long :)
I can't say how UI elements are handled exactly in 3d engines (I want to try UE4 since Sailerius posted an entry tutorial for it but haven't found the time) but keeping a 3d face in front of the camera shouldn't be a performance intensive task. Considering a rectangular UI element made up in a single quad or two tris. You need to create the transformation matrix so the quad/tri can be placed in the correct location with the correct angle relative to the camera. That is the kind of calculation the hardware is performing all the time with every visible model and every visible face (and determining if it can avoid drawing a face altogether). It sounds more like you're trying to optimize too soon and worrying about the cost of having a UI element as a 3d object. Focus on getting something working first, the experience you get from that is far more valuable, you can find what the actual bottlenecks are over theoretical ones, and modern computers and GPUs have so much juice you aren't desperate for every clock cycle.
Again, I don't make game engines and my experience with them is very limited. You and your friend would probably be better served asking people on another site where people have more experience with that stuff. GameDev.net might be a good place to start.
Again, I don't make game engines and my experience with them is very limited. You and your friend would probably be better served asking people on another site where people have more experience with that stuff. GameDev.net might be a good place to start.
Well, i kinda left from there because i lean to rpgs more while gamedev.net is much more general. No complains, a friend is hanging out there for the information.
I hope to stay around the community here because of the more similar preferences.
So tiring to jump around sites. :/
especially since our country's internet is bollocks.
To add on top of it, i have like, zero understanding of programming "grammar" of sorts. :O
Oh and as for the UI elements, that's quite an enlightment.
I found similar case in RUby too just awhile ago, when i tried to bring battler's sprite behind the fighting GUI so that they would exist in the battlefield indefinitely. I went for a check again just to be sure and yes turns out regardless of 2d or 3d, each objects are calculated by the dimension it owns anyway, hence a 2d gui would still have a Z info embedded in it, like when it layers on top of another 2d elements.
But then one other words come up, and it's HUD.
And instead of a plane, an HUD is usually another scene overlayed on top of the other. instead of thinking that the UI exists inthe 3d setup like how the real world seems to work, it is entirely an internal drawing capacity available in graphic engines.
Would that be something of a 2D or 3D engine?
It seems like my understanding of how games are "drawn" is pretty shallow too.
And lots of currently available tutorials are directing you to make a GUi in a 3d space, complete with 3d collider as a selector.
is this all making any sense to you?
I hope to stay around the community here because of the more similar preferences.
So tiring to jump around sites. :/
especially since our country's internet is bollocks.
To add on top of it, i have like, zero understanding of programming "grammar" of sorts. :O
Oh and as for the UI elements, that's quite an enlightment.
I found similar case in RUby too just awhile ago, when i tried to bring battler's sprite behind the fighting GUI so that they would exist in the battlefield indefinitely. I went for a check again just to be sure and yes turns out regardless of 2d or 3d, each objects are calculated by the dimension it owns anyway, hence a 2d gui would still have a Z info embedded in it, like when it layers on top of another 2d elements.
But then one other words come up, and it's HUD.
And instead of a plane, an HUD is usually another scene overlayed on top of the other. instead of thinking that the UI exists inthe 3d setup like how the real world seems to work, it is entirely an internal drawing capacity available in graphic engines.
Would that be something of a 2D or 3D engine?
It seems like my understanding of how games are "drawn" is pretty shallow too.
And lots of currently available tutorials are directing you to make a GUi in a 3d space, complete with 3d collider as a selector.
is this all making any sense to you?
RPG chat here is fine but engine design is out of the scope of what most people here can talk about. WolfCoder is actually making their own RPG Maker engine but that's about it here that I know of.
I can't say much more about 3d engines, like a 3d collider is beyond what I know. I know a few things about VXP Ace drawing (sprites don't only have a z value, but they can belong to a viewport which has its own x, y, and z as a means of controlling how visible elements are drawn in relation to each other!). I'll have to bow out before I show even more of my ignorance on these matters and wish you luck on your team's effort to make their own engine.
I can't say much more about 3d engines, like a 3d collider is beyond what I know. I know a few things about VXP Ace drawing (sprites don't only have a z value, but they can belong to a viewport which has its own x, y, and z as a means of controlling how visible elements are drawn in relation to each other!). I'll have to bow out before I show even more of my ignorance on these matters and wish you luck on your team's effort to make their own engine.
Ah, my previous observation and critical thinking also owes it to my friend who is a general programmer. I'm more of the guy who draw and animate things.
It seems like being the guy who code is not the same as the guy who design.
There are still many things we need to discover.
Thank you for your insights, we're not really looking to make a "new" engine as of yet, just trying to modify the preexisting engine to suit our need.
It seems like being the guy who code is not the same as the guy who design.
There are still many things we need to discover.
Thank you for your insights, we're not really looking to make a "new" engine as of yet, just trying to modify the preexisting engine to suit our need.
amerk
2539
Sadly, Japan has received a lot of RM titles for various gaming devices never released to the US (from Super Nintendo, through Gameboy and GBA, and the Nintendo DS).
If I'm not mistaken, ASCII and Agetec had a hand with RM2 and 3. Had they continued, I'm sure they would have tackled more 3d versions. But now Enterbrain seems to have taken completely over and as far as we've heard from Degica, they have zero interest in making another 3d RPG Maker.
If I'm not mistaken, ASCII and Agetec had a hand with RM2 and 3. Had they continued, I'm sure they would have tackled more 3d versions. But now Enterbrain seems to have taken completely over and as far as we've heard from Degica, they have zero interest in making another 3d RPG Maker.
macblo
85
I took a look at the list of RPG Maker programs on the wiki. There were.. a lot of them. I'm surprised that they even brought over the PS1 and 2 RPG Makers.
