xdaniel

GLSL is more work for me because I've never worked with GLSL, while I know (enough at least) ARB assembly. That wasn't supposed to be rude at all, I'm sorry if it came across as such. It just seemed to me like you think that I barely have an idea how the combiner works or how to emulate it, despite having co-created things like OZMAV2. And that "my" was in quotation marks to signify the co-creation thing, as I'm not the sole author of at least the C-based projects I've worked on; it wasn't meant to imply ex. anything in comparison to your programs or somesuch. ARB is short for the Architecture Review Board of OpenGL which created GLSL. They've approved/created extensions to OpenGL - ones that don't even have anything to do with shaders to boot - since long before GLSL even existed. And as you can see from that specs document for ARB_texture_mirrored_repeat, which is right on the OpenGL website and not Wikipedia or anywhere, it's status is "Complete. Approved by ARB on October 16, 2001." So yes, it is over ten years old, and I have no idea why your 2011 GPU doesn't support it when my rather low-end 2010 GPU does, just like my previous 2007 one (GeForce 8500GT) did. Intel didn't care? Too old and useless an extension in their eyes? Really, no idea.

I'm just talking about rendering the .obj models, plus vertex colors that would be added to the parsed .obj model in the program. When not using shaders and just relying on OGL's fixed function stuff - so glColor, glVertex, etc. instead of vertex shaders - I can specific more than one color, but only the alpha channel of one of them (diffuse) can be used to specific translucency when rendering. With ARB_fragment_program, I'd just have to write a few lines of ARB assembly (see the sample code on the Wikipedia page I linked to) to combine the necessary colors, which is thus also far from a large burden, as long as the OpenGL implementation/graphics card/drivers/whatever of the system that the program runs on supports the extension. That's why I've started the whole survey thing in the first place as, when I used that extension before, some people ended up having rendering problems as their hardware did not, or not correctly support the extension. And as for combiner emulation, that's even less of a problem as it's already being almost fully emulated by OZMAV2 (or libbadRDP rather, in C), SayakaGL (C#) and another handful of "my" programs, so taking that code and reusing it is just copy and paste. Also, regarding ARB_texture_mirrored_repeat, it is ARB and over ten years old: http://www.opengl.org/registry/specs/ARB/texture_mirrored_repeat.txt

ARB assembly language (the extension ARB_fragment_program in particular), not GLSL, and to explain the situation in more detail: From all I know, with rendering using OpenGL's fixed function pipeline - which is what I'd use because I'm used to it, despite it being deprecated in OpenGL 3.0 and removed in 3.1, and the other way would be shaders anyway - transparency/translucency can only come from one source, the diffuse color, but there'd be two possible sources in the model converter, material color (Ka or Kd, plus Tr/d for translucency in an .obj) and vertex color (not officially part of the .obj format, but would/should be editable in-program at least). Both of them could be used at the same time, ex. having translucent water via a material that's not fully opaque, and having a decal of some kind (different grass, a pathway or whatever) that fades out around the edges, or even both on the same surface, but they cannot be rendered correctly at the same time. It might be possible to work around this limitation with surfaces that use just one of the two "types" of transparency, but I cannot say for sure, I'd need to try this out. Also, while texture mirroring is actually easily done - IIRC via ARB_texture_mirrored_repeat, which should be supported by pretty much everything out there -, there's something else that just cannot be done otherwise, and which I'd like to support somehow: multi-texturing. Well, I guess it can be done (ARB_multitexture), but that method appears to be too limited to accurately preview how it would look in-game. (Hope that made some sense, I'm kinda tired by now, pretty late over here)

Okay, first of all, I haven't forgotten about this thread. A lot of thinking is being done on this subject, but I cannot and will not promise anything for now. Next, I'd like to start a bit of a survey about everyone's computers. This is regarding the 3D preview an importer like I imagine it (meaning SharpOcarina-ish) would have, and how accurate I could make it for, for example, per-surface and per-vertex transparency and colorization. OpenGL can only do so much there before I'd have to use more advanced features like, in short, shaders to simulate what the N64's color combiner can do. So, what kind of graphics card or chipset do you have? An Intel GMA, an older Radeon or GeForce? A more modern Radeon HD, GeForce GTX or somesuch? Please post what model it is! And while less important, so it's no big deal if you don't know, how much video RAM do you have? In my case, it would be an ATI Radeon HD 5450 with 512 MB RAM.

You can make games on any console that has a Basic interpreter, so a lot of them from I guess Famicom and up. Not to mention game creation tools like Dezaemon or RPG Maker...

SayakaGL? At least in v0.1.1x, not in the earlier ones IIRC. Also, congratulations from me too, Flotonic, it's getting better and better

http://magicstone.de/dzd/random/SO-v065-TEST2.rar For those with window sizing problems because of ancient screen resolutions ...some issues <.< Sure hope this works now.

fripSide - sister's noise - Toaru Kagaku no Railgun S OP(1) ( )

http://magicstone.de/dzd/random/SO-v065-TEST.rar Tell me if this fixes any known bugs, tell me if this breaks even more in an already fragile program.

Toaru Kagaku no Railgun S Episode 5:

Wait, it doesn't? That'd be one of my main reasons for getting a flashcart. Only reason I can see for it not working is the missing real-time clock, but I don't think emulators emulate that either...? Then again, I have neither flash cartridge so I might be wrong...

As much as memes about cake and lies are tired. And on the subject of nightmares, what's the better fuel? Nightmare fuel or high-octane nightmare fuel?

The show with Scott Bakula and Dean Stockwell? If so, I've seen some episodes of it years and years ago... Think my mom followed it and really liked it during its first run over here, in the early 90s. (Liking Sliders too, btw, at least the first two or so seasons - the later ones with those aliens or whatever? Nah...)

http://magicstone.de/dzd/random/ECDV-1.rar Keep going JSA, I think I'm pretty much done with this. I'll try to get one more thing working - namely simulating camera movement according to the position and focus points in the 3D view - and will release the source in a few days or so, regardless of that feature working or not.

Zelda, because FF is... meh, I dunno. I tried even the supposedly great ones like 4 and 6, but... It's telling that my favorite of those I played is probably FF Tactics Advance? Cola or lemonade?

World creation cutscene, the part with the rocks and the fog...? ...and to curb any potential high-flying hopes for this: If anything, it'll be a glorified hex viewer with some OpenGL stuff bolted on. This will NOT allow cutscene editing, this will NOT be very user-friendly, this WILL have bugs. It's just an experiment.

According to the Wiki, one is the camera position (0x00000001) while the other is the camera focus (i.e. what point the camera is looking at?, 0x00000002), I just forgot what color I gave which...

Ughhh... I hate cutscenes. I was hoping writing some sort of visualizer would help me understand them better, but... it just gets more confusing instead. Doesn't help that I'm probably not parsing them 100% correctly, AND doesn't help that there's no rhyme or reason to the "commands" either <.< This is... camera data for... stupid fairy bumps into fence... maybe?

You darn kids! I was out there in the wilderness catching Scythers and Kangaskhans when you were still little babies! ...but joking aside, welcome to The GCN! Feels like we've got many artists joining recently, almost makes me jealous of you guys and girls!

It's 50-50 I think. SO has its bugs, but there's also exporters that create somewhat weird .obj files, for the lack of a better word - perfectly valid in regards to the (not very strict anyway) file format, but going against some typical conventions I've seen so far.

As JeDDyD said, make sure you use the latest version of SO (although it's v0.6, not v1.6), because that one can triangulate surfaces on its own. It's not perfect, surfaces with too many vertices will fail, but it works better at least.

May I say QWERTZ? ...if not, QWERTY, as it's the closest to what I've used for most of my life. Laptop or tablet?

No, the cutscene data for the title screen does not start there, it starts where I said it does, because that's where the pointer in the scene header points to. The game does not just randomly jump back 0x30 bytes of where a pointer leads!As for rotation, as I shouted I don't know how they work or if they even exist in the cutscene data, but judging from your shouts afterwards you figured this out?And I mentioned 0x0000000A because it seemed to me from you post, that you were saying that that's a new finding. If that's not what you meant, I apologize.

Your "Official start of cutscene"... I don't know what that is but it's before the cutscene data, why do you think that's the start? The cutscene command in the intro's scene header points to 0xA920 in the scene file, or 0x027E0920 in the Debug ROM, two bytes before what you call "cutscene variable" in your image. Edit, btw: That's already on the wiki, format (for the most part) and all.

inb4 Zelda Informer making a big news post for this crap