|
| ||
| Views: 1,610,116 | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search | 11-24-24 02:10 AM |
| Guest: | ||
| 0 users reading So what are we providing with devkitARM for shaders? | 1 bot |
| Main - Homebrew tools - So what are we providing with devkitARM for shaders? | Hide post layouts | New reply |
| StapleButter |
| ||
|
Member blarg Level: 30 
Posts: 51/184 EXP: 151411 Next: 14458 Since: 10-27-14 From: France Last post: 2651 days ago Last view: 2561 days ago |
The thing is that the available tools aren't concurrent, but rather, complementary. aemstro aims at being as low-level as possible to make it possible to mess with undocumented features and such. nihstro on the other hand aims at having a more high-level and sane syntax.
The issue is that the two have different and incompatible shader ASM languages. ____________________ blargSNES -- SNES emu for 3DS More cool stuff |
| neobrain |
| ||
|
Member Normal user Level: 10 Posts: 6/17 EXP: 4241 Next: 173 Since: 11-15-14 Last post: 3316 days ago Last view: 2805 days ago |
Just a quick overview:
smea's aemstro: - scope: assembler + disassembler - dependencies: python3 (runtime) - history: was the first shader (dis)assembler to be published and kind of a playground for reverse-engineering shaders - usability: it works, but isn't really tailored for easy or convenient use. - prospects: I think given the alternatives and smea's amount of free time, there are no plans on making it more usable for homebrew developers. neobrain's nihstro: - scope: assembler + disassembler + C++-library - dependencies: boost (compile-time), C++11 (compile-time), CMake (compile-time) - history: created because a shader disassembler had to be written for Citra anyway; the assembler component is the result of me wanting to try out boost::spirit. - usability: shader language is design for convenient usage - prospects: actively maintained, but the assembler hasn't received any work recently, mostly because of the seemingly general lack of interest in GPU homebrew development. fincs's picasso: - scope: assembler - dependencies: autotools, TDM-GCC (on Windows; compile-time) - history: written after aemstro and nihstro because both were considered to be lacking in different aspects by the author - usability: follows syntax similar to nihstro - prospects: it hasn't been updated in a while. It's only an assembler. My (biased) opinion is that aemstro isn't going anywhere and picasso is built on arguably inferior technology, but probably "good enough" for most people. As for nihstro, I would probably put the assembler portion higher on my TODO list if more people actually started creating 3DS homebrew using the GPU. In any case, picasso is probably the only thing suitable for inclusion into devkitARM, because including nihstro (apparently) means including boost, which is (understandably) unacceptable for the DKA maintainers. None of that is relevant for homebrew developers though, since those will probably use a binary distribution anyway. However, I don't think we desperately need to have a shader assembler included in DKA if that makes for a less pleasant development experience, especially since we don't really know yet which of the three projects will remain active in the long run. If people insist on shipping *something* with DKA, I would say let things cool down for another few months and see which of the three projects is most advanced by then and/or most commonly used by homebrew developers. That's better than imposing some default onto people (who will probably think it's the only option available) and making them convert over half their code base when they realize the external tools end up being superior. If nihstro turns out to be the favorite, then I guess it would be best to simply not ever include a shader assembler in DKA. |
| StapleButter |
| ||
|
Member blarg Level: 30
Posts: 54/184 EXP: 151411 Next: 14458 Since: 10-27-14 From: France Last post: 2651 days ago Last view: 2561 days ago |
Well yeah, you have a good point. It would become an issue though if people had to download a billion external tools to build others' 3DS homebrew projects. But then again, why would one want to build a ton of homebrew projects if those can be downloaded in built form? (unless they're EmuCR; in that case, fuck them)
Encouraging general GPU use is also a thing we need to work on, yeah. Wondering how far minexew's ctrGL is. The GPU is probably still seen as "oh god that ubercomplex thing that freezes if you do anything wrong", which isn't really the case anymore with the last ctrulib fixes. GPU usage needs to be encouraged too as the 3DS is too slow for full framebuffer-based drawing. ____________________ blargSNES -- SNES emu for 3DS More cool stuff |
| Tcm0 |
| ||
|
Newcomer Normal user Level: 6 Posts: 4/6 EXP: 884 Next: 23 Since: 12-29-14 Last post: 3548 days ago Last view: 3009 days ago |
I think that the "general noobish homebrew developer" needs some good samples for the assemblers: how to display images, backgrounds, (custom) fonts and 3d graphics well organized at one place. At least that's what I would want to start using the GPU.
/edit A good documentation would probably be usefull, too. |
| StapleButter |
| ||
|
Member blarg Level: 30
Posts: 55/184 EXP: 151411 Next: 14458 Since: 10-27-14 From: France Last post: 2651 days ago Last view: 2561 days ago |
And some 'default' shaders that are basically a fixed pipeline, too.
The issue with that is that what input attributes mean pretty much depends on what the shaders do. But we'd just have to document the mapping for the default shaders and call it good... or something. ____________________ blargSNES -- SNES emu for 3DS More cool stuff |
| sgowen |
| ||
|
Newcomer Normal user Level: 7 Posts: 1/7 EXP: 1077 Next: 371 Since: 08-21-15 From: Gallatin, TN Last post: 3355 days ago Last view: 3319 days ago |
Has there been any progress on this?
If I could get my hands on a good GPU example, I would update my Tappy Plane port. It already has shaders written in GLSL and HLSL; I just don't know anything about PICA200 or how to really control it. So currently, Tappy Plane is a playable game of white squares and triangles. I saw the "textured_cube" in ctrulib, but I couldn't get it working due to picasso compilation issues on my Mac. I might just try nihstro (seems to be more homebrew newbie friendly), but it would be great if we could get some basic examples using it and further on down the road removing the dependency on Boost if possible. Thoughts? |
| neobrain |
| ||
|
Member Normal user Level: 10 Posts: 15/17 EXP: 4241 Next: 173 Since: 11-15-14 Last post: 3316 days ago Last view: 2805 days ago |
The current situation is that future releases of devkitARM will ship with picasso by default, whereas nihstro will continue to be actively developed outside of that. For instance, I just recently added an ".include" feature similar to C's "#include" directive.
As you point out, nihstro indeed is intended to be more homebrew developer friendly than other shader assemblers, and I still think it succeeds in doing so. I'm also very much open for suggestions and/or "first time use" experience reports. As for examples: ctrulib ships with a number of examples using picasso, whereas nihstro includes its own bunch of examples (see the examples/assember directory). Ultimately you can get any of the examples working with either assembler - it's just that each project hardcodes its respective "default assembler" in the Makefile, which you could easily change if need be, however. As for removing the boost dependency, that's unfortunately not going to happen because it helps me a lot in ultimately creating a better program. Also, replacing the boost portions would waste a lot of time that I could spend on adding new features instead. |
| sgowen |
| ||
|
Newcomer Normal user Level: 7 Posts: 2/7 EXP: 1077 Next: 371 Since: 08-21-15 From: Gallatin, TN Last post: 3355 days ago Last view: 3319 days ago |
neobrain,
That makes sense. I think in the meantime, before learning the internals of PICA200, I am just going to be using the sf2dlib library for porting my less complex games. Whenever I am ready to move towards full GPU-involved work, I will definitely check out the latest and greatest from nihstro. Until then, I look forward to seeing how it evolves! |
| Main - Homebrew tools - So what are we providing with devkitARM for shaders? | Hide post layouts | New reply |
|
Page rendered in 0.018 seconds. (2048KB of memory used) MySQL - queries: 28, rows: 79/79, time: 0.006 seconds. ![[powered by Acmlm]](img/poweredbyacmlm.png "powering nostalgia")
Acmlmboard 2.064 (2018-07-20)© 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |