Image Map Image Map
Page 1 of 4 1234 LastLast
Results 1 to 10 of 33

Thread: Maker4D the RPG Game Maker Engine

  1. Default Maker4D the RPG Game Maker Engine

    Maker4D is a FREE 3D rpg game maker engine, with pre-rendered background, and real time 3D battle. (Similar to Final Fantasy 7 or 8, or Alone In The Dark). It is also capable to make Visual Novels, and it can dynamically switch bethwen 2D or 3D mode. Maker4D is a free RPG game maker engine that automatically generates your playable 3D characters from 2D picture of your hero.

    This game engine uses software rendering, and very tiny amout of RAM.

    I have decided to optimize this game engine to be able to run on 486's, P1 class computers.

    maker4dscreenshot.jpg

    Maker4D has no editor, it automatically generates the game based on the files you created. To make a game with Maker4D, you have to do a directory for every room (map), then copy the background to the map directory (background.jpg), and put your playable character in as hero.png. Maker4D can be also used to create 2D Visual Novel games.

    maker4dscreenshot2.jpg

    What i have did so far:
    I have tested it on a Cyrix 6x86MX 200 mhz CPU. It turned out it runs, but only on 0.7 fps.
    After i have profiled out the passes of the 3D engine, it turned out the main factor that slowed down the rendering was the animation code. On a modern 64 bit computer it ran without issue as it solved the problem with muscle, but on cyrix, it bottlenecked the overall rendering. https://streamable.com/3acft Now i have like 1.2 fps.
    My next goal is to reach 2 fps on that Cyrix.


    download: http://maker4d.uw.hu/index.html

  2. #2

    Default

    I think you're going to have a time of it optimizing code written with a Pentium 4 as a minimum target to run on 486-class systems. Additionally, did you notice the bit on the download page where it expressly forbids modifying the software or distributing modified versions?

    That said, I think you could definitely pull off an FF7-esque pre-rendered backdrop/3D character model RPG system on 486-era hardware (though full 3D environments for battles might be a bit much to shoot for, but something like Golden Sun's faux-3D multi-layer panorama backdrops might be doable.) You'd just probably be better served writing it from scratch rather than trying to back-port software that was never designed for the limitations of these systems.
    Computers: Amiga 1200, DEC VAXStation 4000/60, DEC MicroPDP-11/73
    Synthesizers: Roland JX-10/SH-09/MT-32/D-50, Yamaha DX7-II/V50/TX7/TG33/FB-01, Korg MS-20 Mini/ARP Odyssey/DW-8000/X5DR, Ensoniq SQ-80, E-mu Proteus/2, Moog Satellite, Oberheim SEM
    "'Legacy code' often differs from its suggested alternative by actually working and scaling." - Bjarne Stroustrup

  3. Default

    Hello. First, thank you for your reply.

    Quote Originally Posted by commodorejohn View Post
    I think you're going to have a time of it optimizing code written with a Pentium 4 as a minimum target to run on 486-class systems. Additionally, did you notice the bit on the download page where it expressly forbids modifying the software or distributing modified versions?
    You misunderstood something, this is my software.

    And i originally designed it to run on 64 bit computers with 2 core, and not for P4-s. However, being able to run it on old computers were also in priority, so i compiled 5x86 capable binaries from the beginning. (This software is released a month ago, since then i did two updates on it).

    Quote Originally Posted by commodorejohn View Post
    That said, I think you could definitely pull off an FF7-esque pre-rendered backdrop/3D character model RPG system on 486-era hardware (though full 3D environments for battles might be a bit much to shoot for, but something like Golden Sun's faux-3D multi-layer panorama backdrops might be doable.)
    Yes. The final fantasy 8 on the psx were also stuttering greatly when the battle system engaged. The frame rate sometimes dropped to like 4-5 fps when it did the battle animations. When the characters just walked around, it was able to maintain fps numbers above 10. Final Fantasy 8, however, used hardware rendering. This uses software rendering. However, software rendering from this era (like the quake for example) can process a couple of 1000 polygons on playable frame rates. So it should be possible for me to go above 1 fps. After carefully testing out the situation, it turns out that moving with 5 fps on the maps will give a satisfactory gameplay.

    I will continue this experiment after i have updated the ram in my socket7 machine.

  4. #4
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    5,942
    Blog Entries
    1

    Default

    Quote Originally Posted by Geri View Post
    After i have profiled out the passes of the 3D engine, it turned out the main factor that slowed down the rendering was the animation code.
    You're going to have a very hard time getting this down to 486 levels, but if you want to try, you should render everything in 320x200 256-color mode 13h because that will give you the easiest learning curve, and the simplest debugging and implementation. Once you get that down, you can work on SVGA resolutions. You'll also have to convert any heavy floating-point operations to fixed-point, since while the 486 does have an embedded math coprocessor, it's not as fast as the Pentium-and-higher implementations.

    An engine like this is possible even on a 286; see Alone in the Dark for a working example. But that's only if the engine is written from scratch with these limitations in mine (as Alone in the Dark was).
    Offering a bounty for:
    - The software "Overhead Express" (doesn't have to be original, can be a copy)
    - A working Sanyo MBC-775, Olivetti M24, or Logabax 1600
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

  5. Default

    Trixter, i originally have designed this 3d renderer to use integer logic. (Otherwise it stutters literally on everything, integer pipelines in the cpu are generally still much faster than floating point logic) This does not apply to the rest of the engine, or the externaly cycles of the engine, those are float. Im not planning to redesign this for 256 color or dos or anything like that, and i will very certainly not add inline assembly or 486 specific quirks. i want to solve this from brain and not from muscle (also the time i will spend on this is limited). I would refer to my previous reply i made a couple hours ago, but it still pending for moderation.

  6. #6
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    5,942
    Blog Entries
    1

    Default

    You wrote "the animation system" was a source of slowdown -- can you be more specific?

    Im not planning to redesign this for 256 color or dos or anything like that
    What is your hardware and OS target? Windows 98 with a 3-D accelerator? Your original message made it sound like you were targeting 486, which implies DOS and software rendering.

    However, software rendering from this era (like the quake for example) can process a couple of 1000 polygons on playable frame rates
    You're off by an order of magnitude. If we're talking 486, it's hundreds of textured lit polygons, not thousands. And quake doesn't run on a 486 (unless you patch it and have a 486 dx4-100, and then it runs badly).
    Offering a bounty for:
    - The software "Overhead Express" (doesn't have to be original, can be a copy)
    - A working Sanyo MBC-775, Olivetti M24, or Logabax 1600
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

  7. Default

    Trixter:

    The animation system is the bone code that allows characters to be animated (for example, to compute the walk). That was a lot of work for this cpu to do it in real time. Sometimes programmers pre-compute this to keyframes, which i dont do. I was afraid i will have to do it, because i didnt wanted to do structural changes. But luckily i dont, i have realized i can get the final values of usually two vertex from previous triangle, steeply cutting down the execution time of the animation code. It originally consumed about 0.5 seconds for each frame. After doing this quirk, it consumes below 0.2s. Thats not significant compared to the time of the rasterizer itself. I think i will able to go below 0.16sec in the animation code if i eliminate the sqrtf and doing some fine tune of the code, and i will be happy with that, at least for now.
    (These times apply on the 200 MHz Cyrix 6x86MX which is also shown on the video i have linked).

    In my opening message i have mentioned 486 and P1 class, so yeah i wasnt clear enough, i should have specified the target more.

    By 486 i have meant the high-end 486-s using the fastest 486-s and 5x86 alternatives for that cpu socket with a lot of ram, running win9x or linux. This software will not be ported for dos.
    (And no 3d acceleration, this engine uses no hardware acceleration. But this does not means i have plans to port it for dos.)

    Currently, the short term goal is to push it above 2 fps on my Cyrix machine.

  8. Default

    I continued the optimization-spree.
    Eliminating sqrtf did not improved the speed. (only 2-3% speedup due to that). It seems sqrtf is not that slow on the Cyrix (or more precisely the multiplications and divisions around it are already slow enough to remove sqrtf from a long code snippet stays unnoticed).

    I did modifications in the shadow code. It decreases the overall polygon count. I hope that will give some fps boost. I will measure it soon.

  9. #9
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    5,942
    Blog Entries
    1

    Default

    Quote Originally Posted by Geri View Post
    Currently, the short term goal is to push it above 2 fps on my Cyrix machine.
    If that's a 200MHz system and you're animating in a 640x480 256-color mode, you should be pushing 15-20 fps, not 2fps. Sounds like you have a ton of optimization work ahead of you. Good luck.
    Offering a bounty for:
    - The software "Overhead Express" (doesn't have to be original, can be a copy)
    - A working Sanyo MBC-775, Olivetti M24, or Logabax 1600
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

  10. Default

    Quote Originally Posted by Trixter View Post
    If that's a 200MHz system and you're animating in a 640x480 256-color mode, you should be pushing 15-20 fps, not 2fps. Sounds like you have a ton of optimization work ahead of you. Good luck.
    i animate polygons and not pixels, but its right, it should be more playable. today i had some time so i continued this strange task to optimize the engine on the cyrix.

    the loading times were too high. i investigated, why. I identifyed and annihilated a nasty speed parasite in the modell generation. I profiled out why its so slow, and everything pointed to one point, the code snipped that filters out polygon duplicates when generating the 3d character models. i fixed it by replacing the comparisons to integer logic where i could. it increased the speed by more than 3x of that practicular code snippet.

    it seems the floating point comparisons on Cyrix is somewhat extremely sluggish, maybe more than 10 or even 15 clock cycle

    i have found another bottlenecks in the rendering itself. now the fps is probably above 1.6 fps

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •