Language…
18 users online: akawo, Alex No,  AmperSam, CharlieUltra, DanMario24YT, edgar, Fullcannon, Gemini0, Green, Gulaschko, Hammerer, Heitor Porfirio,  MarioFanGamer, Metal-Yoshi94, NewPointless, steelsburg, timeisart, Tulip Time Scholarship Games - Guests: 269 - Bots: 383
Users: 64,795 (2,370 active)
Latest user: mathew

Vilela's Random Laboratory

  • Pages:
  • 1
  • 2
Well, bear in mind, 3D works are pretty much possible in a software-level if you have good knowledge and if you know pretty much how to apply them, this is the case here.

Besides, SA-1 and Super FX aren't different from each other, the only thing that changes, it is that Super FX uses a complete different ASM language, in terms of language, it is even close of MIPS and 32X.

And well, the only issue is that the code doesn't take account buffering, in which GSU does, you can load polygon data while storing the processed polygon on RAM while processing something else while on Cache... I got permission from Vilela but being frank, his code would pretty much benefit from the way Super FX works.

I'm working on a similar project. The OW would be replaced by a set of 2D triangles (not 3D, though 3D can be pre-projected into 2D if desired).

I also have always wanted to make SM64 for the NES (not the SNES), using an orthographic view, and separate maps for occluded areas, that would be warped to when you set foot on a specific tile. For cannons, there would be a pre-rendered 2D map that would be scrolled.
Nice job in that sample streaming patch... but, instead of streaming those big sfx samples, wouldn't be less laggy streaming the original smw samples (or the optimized ones)? for example if a sfx uses the @3, then load it and unload it when the sfx ends.
Dang. How did I not reply to this yet?
I'm a bit disappointed... in myself. Because I tried some 3D rednering on C# from scratch (not using existing libraries and stuff) and while I did manage to do stuff, I didn't get this far even though you used fucking SNES (well, SA-1 but it burns down to the same).
Gotta check out that source if I ever stop being a lazy bum.
As amazing as that is though, I see close to no practical use for it other than maybe cool cutscenes but no real gameplay use :/

The streaming thing... well I guess it's awesome but I don't know shit about custom music, so I really have no idea. Even if you did some god tier custom music stuff, you'd probably not get a good reaction out of me. But knowing you (and the reactions I've seen from people) it seems to be impressive shit. So good job #smw{:TUP:}

Now excuse me, I just had to remember you're like 5 years younger than me, so I gotta sulk in desperation now.
IF ONLY I WAS MORE MOTIVATED!!!
Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?
First of all thanks everyone for the replies. Honestly I got surprised with high amount of positive feedback, considering this is a thing that it is not usable yet in SMW hacks (talking about the 3D polygons).

I should feel bad for not replying before, I'm been busy working working hard on some related projects that will be available on Touhou Mario 2 later. (I still have to comment the other threads as well, oh well).

Originally posted by yoshifanatic
That's some pretty impressive work getting the SA-1 to draw polygons. Given how much you've been able to get out of the SA-1, I have to wonder what isn't possible to do on it. XD I don't think there is all that much potential for using it for 3D compared to, of course, the SuperFX, but it's still pretty cool to see the SA-1 do something like this.


As long you have enough megahertz, megabytes and hardware support everything is possible on a programmable CPU! But yeah you can pretty much implement anything in the SA-1 CPU, it's just a matter of attempting it. I even gave up while working it because it was very complicated to do the conversion process but thank God everything went well in the end. As Disco stated 3D is possible in any machine with software rendering, other easier and another harder.


Quote
As for the sample streaming, I've been wanting something like this for quite some time, so great work! I might attempt to use it for one of my hacks, though avoiding the slowdown and V-blank overflow may make it tricky to use. If you're planning on improving the sample streaming code, perhaps you could look at the coding of the SNES version of Earthworm Jim 2 to see how it did sample streaming since that game was able to manage it without slowdown and it doesn't use any enhancement chips. It's method of doing it doesn't work in ZSNES though, but that's not really an issue since ZSNES is no longer supported by SMWC.


Earthworm Jim 2 focuses on streaming BRR blocks with a very low bitrate using HDMA. This assures that the main CPU won't be affected or interrupted with the streaming but it requires the SPC700 accessing the I/O almost every single time, which unfortunately it's a bit hard to do that from N-SPC because it has some extremely slow routines that can take enough time to lose some BRR blocks, which can lead to pretty bad results. And not just that, the low bitrate isn't very good either.

Originally posted by absentCrowned
Originally posted by Vitor Vilela
Also if someone have a tool request to do, feel free to write here and who knows if I can make it a reality for the next C3? Haha!


SA-1 GPS! (again)


Yeah I always forgot to do that. I won't promise anything, but I hope I get this up before February!

Quote
Also, that stuff you're showing off blows my mind. I don't really have words... I never expected 3D to be possible without SuperFX (or that wireframe thing in MMX1/2). Good job on the sound streaming thing too, great to see it being released.


Thanks, but again 3D is possible at any machine, as long you code it properly within hardware limits. With SA-1 for example you have great advantage with the character conversion DMA and the good multiplication registers (32-bit), but you have on the other side the high rasterization difficult due of the architecture, the lack of a barrel shift or a plot command for example.

This video linked from p4plus2 actually inspired me to do that. It's a pretty impressive Atari demo using 65c816 as CPU. Due of the similar architecture (CPU), I imagined that some simple 3D drawing would be possible using SNES/SA-1 too (actually p4plus2 challenged me to port the demo to SNES/SA-1 but figured it would be a bit too difficult).

Originally posted by zack30
Wow, so, umm. . .3D graphics in the SMW engine. That is kinda insane, probably the first EVER 3D models i've seen done in SMW hacking, because honestly, I don't think it's been done anywhere else.

200 polys at 5 FPS however? That's kinda really sluggish. It might be able to handle more basic objects, like some of the 3D platforms in Yoshi's Island with a very likely chance of slowdown to 30FPS, though.

Also, have you tried pushing out higher resolutions with the more basic objects? (I.E: The cube objects, nothing like the Mario model) Like, just make small increments, like start with 160x120, then 160x144, then 208x176, ETC, until it crashes even trying to render the cube.


EDIT: Just found a SNES tech demo ("2.68 MHz Demo" - by Abandon) showcasing 3D objects being rendered by the SNES itself, no coprocessor, using the 2.68MHz clock speed, not even FastROM.
It even seems to be rendered at the SNES' default screen resolution - 256x224.
(I assume the screen resolution from comparing another emulator window open, running SMW with the same screen size as the other window, which is running the demo.)

2.68 MHz Demo by Abandon (Skips to the 3D objects part)


As I told you though PM, it's possible to speed up that Mario into up to ~15 FPS by making some insane optimizations like caching vertice calculations and using a better z-sorting method (for example I recently changed bubble sort to insertion sort and I gained 2 FPS when viewing the SSB mario model).

The resolution is variable, it's more for a SNES limitation than SA-1 limitation. You can't really make a big 3D screen without using f-blank help or double buffering it so I have twice time (but lowers to 30 FPS).

And that demo frame buffer actually is 128x128, it's just the logo giving an impression that is full screen.

Originally posted by LadiesMan217
I wonder if this is how Jurassic Park did it's first person levels? If that's the case, imagine making a first person level all the way!!! Omg, if this is possible one day with an SMW ROM, imagiine the possibilities.


That Jurassic Pack level actually is extremely impressive. Not just it's 3D but completely textured. Honestly I have no idea how they did it but I bet it involves lot of pre-rendering because obviously SNES CPU can't do it at real time.

Originally posted by DiscoTheBat
And well, the only issue is that the code doesn't take account buffering, in which GSU does, you can load polygon data while storing the processed polygon on RAM while processing something else while on Cache... I got permission from Vilela but being frank, his code would pretty much benefit from the way Super FX works


Buffering? I don't quite get it but if you mean about the CACHE command while doing something else(???), I don't really know how much it would benefit compared to regular processing.

Originally posted by Pinci
Nice job in that sample streaming patch... but, instead of streaming those big sfx samples, wouldn't be less laggy streaming the original smw samples (or the optimized ones)? for example if a sfx uses the @3, then load it and unload it when the sfx ends.


Not a bad idea either but it would require reserving some ARAM space and it would have a small delay because the SFX would only play after the instrument was fully loaded and you can't take in account the sfx's pitch changes.

Once I tried making SA-1 process all music and sfx data from ROM and just leave to ARAM the samples, echo buffer and a small software to write data to DSP/ARAM but I never got the N-SPC engine working properly with the chip.

The benefits from having it is that you would have all ~63KB ARAM to put your samples and echo buffer, "infinite" SFX/.txt compiled music data (because they would be in the ROM instead) and because of that instant music switching (if they use the same samples).

Originally posted by JackTheSpades
Dang. How did I not reply to this yet?
I'm a bit disappointed... in myself. Because I tried some 3D rednering on C# from scratch (not using existing libraries and stuff) and while I did manage to do stuff, I didn't get this far even though you used fucking SNES (well, SA-1 but it burns down to the same).
Gotta check out that source if I ever stop being a lazy bum.
As amazing as that is though, I see close to no practical use for it other than maybe cool cutscenes but no real gameplay use :/


In the readme included there's a page that teaches you how to do 3D drawing using GDI+ and simple matrix math that I used as a base. That may be useful for you :)

Quote
Now excuse me, I just had to remember you're like 5 years younger than me, so I gotta sulk in desperation now.
IF ONLY I WAS MORE MOTIVATED!!!


lol

I'm not that young anymore though.
GitHub - Twitter - YouTube - SnesLab Discord
Originally posted by Vitor Vilela
I'm not that young anymore though.

Well neither am I, but strangely enough, our age difference should still be around the same.
Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?
The Jurassic Park thing looks like it is not full 3D as it limits viewing angles from going up and down (similar to Wolfenstein, I think). It is actually really simple (compared to full 3D) to do that (Link).
Your layout has been removed.
  • Pages:
  • 1
  • 2