|
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
|
Originally posted by Stevoisiak
Originally posted by VL-Tone
Originally posted by Stevoisiak
I say for now just release a small seperate app for the importer. (Like you did with the text editor)
That's a good idea, I didn't think about that... The problem is that the current version of TT64 is dependent on the already generated m64geometry file to draw polygons. To load modified polygons you need to delete that file so it will be re-generated when opening the ROM, and you'd have to do that each time you re-import your .obj file.
My current development version (which will be version 6.0) decode polygon in RAM gradually as needed and can reload specific models when requested, such as when you import a new level geometry.
Yeah, I was thinking that would be a good idea. For now though, maybe TT can just check if there are any model errors and if so, regenerate the file. Or just have a question on startup asking to remake it.
The idea behind releasing a separate importer would be to avoid releasing a new TT64 just for the basic incomplete importer. If I have to release a new version of TT64 just to support the separate importer, it kind of defeat the purpose. The only advantage would be that I could publish an update to the editor only, but even then, I could end up having to update both programs back and forth.
Originally posted by Ratchetfan19
VL-Tone, do you have an idea of how many polygons/vertices the graphics engine can handle without slowing the game down? Actually, you might as well code a generic limit because if the game runs fine one moment, it could slow down another depending on what's currently loaded.
But that raises another question. Now it's obvious that any graphics engine has its limits, but why does the game slow down when it approaches the 240 object limit? For example, I can create 200 objects in Flatworld with no sprites and no behavior, and the game would still slow down. Is it a result of "external" coding that runs in the background for each object?
The game will slow down if it has too much polygons on-screen at the same time. So it all depends on the level design. Still, the original levels in SM64 were designed so you can get the whole level in the screen in some situations (when flying way up) without slow-downs. That's why levels in SM64 are relatively low-polygon, compared to games like Crash Bandicot on the PS1, which managed to get more polygons in levels by putting you on a pre-defined path that prevented you from ever seeing the level as a whole, and putting walls of vegetations to hide the rest of the level.
Modern games often to "cheat" like that, while the 3d Mario games (SM64 SMS and SMG) made the compromise of having lower resolution levels (textures and polys) but gaining the benefit of a greater sense of "freedom", where you can see far away, fly around and see the whole level at once, and not being restricted to specific paths and feeling enclosed by walls and stuff.
Anyway, all that to say that it depends. The real limit is more about RAM, because SM64 doesn't use the extension pack, and the polygon data must be kept in RAM while being displayed.
As for the empty objects slowing down the game, the problem is that behavior 0x0000 is not an empty behavior, it's one that has to calculate Mario's proximity to it. The trick to prevent an empty object from slowing down a level is to make sure that they don't appear in any acts (the little stars should all be gray in the parameter bar). But there should be a better way to "delete" objects, I'll see what I can do.
____________________
|
  |
|
|