xdaniel's Random Junk

[xdaniel]

Hrm, not sure if I want to mess around with the drive... My PAL DC already had problems reading GDs and CDs when I pulled the PSU board out to put it into my NTSC DC - the one I'm mainly using now - and that one's still working fine, so I don't want to risk messing it up...

 

That aside, 58 to 62 FPS according to code and 54%/32 VPS according to emulator, at 64 models rendered, one texture load per group, all rotating independently:

 

 

 

 

Hardware testing tomorrow, I guess... or today, considering the time of day.

 

EDIT: Haven't tested on hardware yet, but have redone the model format. A simplified explanation of the format... There's two important parts to it now, header aside, down from three: texture data and geometry data. Texture data consists of a pointer table and the actual texture information (dimensions, pixel data, etc) the table points to. Geometry data consists of lists of vertices on a per-texture basis. So the first list contains all the vertices that use one texture, the next list contains all vertices using another texture, and so on.

 

There's some superfluous data still in there that I'll optimize out for the next version of the format (i.e. when I actually try and port over EO1 dungeon maps), but for now it's working pretty well. That leaves the performance checks on real hardware as the next short-term goal...

 

 

 

Edited October 18, 2013 by xdaniel

[xdaniel]

It's like I'm subconsciously telling myself "screw checking on hardware, add moar stuffz!!"... because here's my home-grown font and text printing class in action:

 

 

(don't mind me screwing around there )

 

 

...actually, part of the hardware testing involves, well, being able to read the FPS somehow after all. And the text printing functionality I've used before, ex. in the Parallax library, doesn't seem to play nice with the optimized DMA-based vertex loading, so I needed to write something myself that does support this correctly...

 

Anyway, custom binary font format (+ converter written in C#, similar to the model format), print function takes printf-style format strings and parameters (%s, %f, etc.), text color and scaling can be set prior to printing. It's still a bit limited in features and clumsily put together, so this'll need more cleaning up and other improvements, and I want to add control codes for coloring, at least, at some point.

 

Will look for those last few CD-Rs one of these days and (after, I dunno, three, four years?) buy a new spindle of them next month...

[xdaniel]

Meh, decided to look for the CD-Rs just before going to bed, found them, burned the image to the disk, and... ugh...

 

 

...the orange FPS bar looks like crap and is useless! Because it really does run at roughly 60 FPS! Super-smooth rotation on the models! Fonts look great on the screen, too!

 

 

Still wanna know why it fluctuates around (and especially goes above) the 60 FPS mark like this...

 

 

EDIT: Bugfixes, improvements, and a new debug menu!

 

 

 

Edited October 24, 2013 by xdaniel

[xdaniel]

Let's see...

• SVN'd "DCEO2" and "Frenda", meaning the game part and the engine part of the project; messed up at some point during a mass renaming of files, tho, which had resulted in me having to recreate the repository for DCEO2. Everything's working fine now, but I gotta watch out for this when refactoring part of the engine soon...

   

• Some under-the-hood fixes and improvements to the debug menu state and the menu manager; also optimized away spaces in strings in the font system. Previously it actually rendered empty polygons for the spaces, now it skips drawing them and just increases the X coordinate according to the whitespace width.

   

• Started writing the NSBMD exporter, to get EO1's dungeon models out of the game... or, well, more like "started hacking up my experimental NSBMD Viewer to dump all vertices into an XML file":

   

  

EDIT:

• Optimized Frenda 3D model format into "Fr3Dv03", got rid of some superfluous values; think the format's pretty much perfect for my purposes now.

Edited October 27, 2013 by xdaniel

[Airikita]

It works on console too? Does that mean you figured out the issue with OoT models? Btw, it all looks fantastic!

[xdaniel]

On console, yes, but on Dreamcast. It's a project I'm working on for DC and that room from SharpOcarina's demo scene is just something for testing purposes that I had handy.

[Conker]

Unnngh, you make so much awesome.

[Airikita]

On console, yes, but on Dreamcast. It's a project I'm working on for DC and that room from SharpOcarina's demo scene is just something for testing purposes that I had handy.

Oh I see, neat~!

[xdaniel]

Yay! I got it! I finally got it!!

 

 

 

Not perfect yet (problems with alpha channels, some clipping glitches when the camera is too close), but it's getting there~! <3 Also thinking I'll need to change the model format once more, so that multiple models can be stored in a single file, like the original NSBMD format works...

 

Also, the text in the spoiler below (which my NSBMD Viewer dumps, and which is basically the OpenGL calls used for drawing, just slightly modified) is what's turned into the model from the first screenshot in the spoiler above (which my Fr3D model converter does):

 

 

// d01_g13

/* 01_02 */
GL.Begin(BeginMode.Quads);

	GL.TexCoord2(255, 127);
	GL.Color4(0.8064516, 1, 0.7419355, 1);
	GL.Vertex3(0, 0, 2);

	GL.TexCoord2(255, 0);
	GL.Color4(0.516129, 0.7741935, 0.9354839, 1);
	GL.Vertex3(0, 0, 0);

	GL.TexCoord2(128, 0);
	GL.Color4(0.8064516, 1, 0.7419355, 1);
	GL.Vertex3(-2, 0, 0);

	GL.TexCoord2(128, 127);
	GL.Color4(0.09677419, 0.5806451, 0.5806451, 1);
	GL.Vertex3(-2, 0, 2);

	GL.TexCoord2(128, 127);
	GL.Color4(0.516129, 0.7741935, 0.9354839, 1);
	GL.Vertex3(0, 0, 0);

	GL.TexCoord2(255, 127);
	GL.Color4(0.8064516, 1, 0.7419355, 1);
	GL.Vertex3(0, 0, 2);

	GL.TexCoord2(255, 0);
	GL.Color4(0.09677419, 0.5806451, 0.5806451, 1);
	GL.Vertex3(2, 0, 2);

	GL.TexCoord2(128, 0);
	GL.Color4(0.8064516, 1, 0.7419355, 1);
	GL.Vertex3(2, 0, 0);

	GL.TexCoord2(128, 127);
	GL.Color4(0.09677419, 0.5806451, 0.5806451, 1);
	GL.Vertex3(-2, 0, -2);

	GL.TexCoord2(255, 127);
	GL.Color4(0.8064516, 1, 0.7419355, 1);
	GL.Vertex3(-2, 0, 0);

	GL.TexCoord2(255, 0);
	GL.Color4(0.516129, 0.7741935, 0.9354839, 1);
	GL.Vertex3(0, 0, 0);

	GL.TexCoord2(128, 0);
	GL.Color4(0.8064516, 1, 0.7419355, 1);
	GL.Vertex3(0, 0, -2);

	GL.TexCoord2(128, 0);
	GL.Color4(0.09677419, 0.5806451, 0.5806451, 1);
	GL.Vertex3(2, 0, -2);

	GL.TexCoord2(128, 127);
	GL.Color4(0.8064516, 1, 0.7419355, 1);
	GL.Vertex3(0, 0, -2);

	GL.TexCoord2(255, 127);
	GL.Color4(0.516129, 0.7741935, 0.9354839, 1);
	GL.Vertex3(0, 0, 0);

	GL.TexCoord2(255, 0);
	GL.Color4(0.8064516, 1, 0.7419355, 1);
	GL.Vertex3(2, 0, 0);

GL.End();

/* d01_t_box */
GL.Begin(BeginMode.TriangleStrip);

	GL.TexCoord2(64, 126);
	GL.Color4(1, 1, 1, 1);
	GL.Vertex3(0.58544921875, -0.02392578125, 0.030029296875);

	GL.TexCoord2(64, 103);
	GL.Color4(0.5483871, 0.483871, 0.3548387, 1);
	GL.Vertex3(0.429443359375, 0.171630859375, 0.0361328125);

	GL.TexCoord2(0, 126);
	GL.Color4(1, 1, 1, 1);
	GL.Vertex3(-0.33544921875, -0.02392578125, 0.6279296875);

	GL.TexCoord2(0, 103);
	GL.Color4(0.5483871, 0.483871, 0.3548387, 1);
	GL.Vertex3(-0.216064453125, 0.1953125, 0.508056640625);

GL.End();

GL.Begin(BeginMode.TriangleStrip);

	GL.TexCoord2(0, 126);
	GL.Color4(1, 1, 1, 1);
	GL.Vertex3(0.58544921875, -0.02392578125, 0.030029296875);

	GL.TexCoord2(64, 126);
	GL.Vertex3(-0.073486328125, -0.02392578125, -0.87548828125);

	GL.TexCoord2(0, 103);
	GL.Color4(0.4193548, 0.3225806, 0.1935484, 1);
	GL.Vertex3(0.429443359375, 0.171630859375, 0.0361328125);

	GL.TexCoord2(64, 103);
	GL.Vertex3(-0.003662109375, 0.46142578125, -0.57080078125);

GL.End();

GL.Begin(BeginMode.TriangleStrip);

	GL.TexCoord2(0, 126);
	GL.Color4(1, 1, 1, 1);
	GL.Vertex3(-0.073486328125, -0.02392578125, -0.87548828125);

	GL.TexCoord2(64, 126);
	GL.Vertex3(-0.906005859375, -0.02392578125, -0.225830078125);

	GL.TexCoord2(0, 103);
	GL.Color4(0.6774194, 0.6451613, 0.4516129, 1);
	GL.Vertex3(-0.003662109375, 0.46142578125, -0.57080078125);

	GL.TexCoord2(64, 103);
	GL.Vertex3(-0.649169921875, 0.48486328125, -0.098876953125);

GL.End();

GL.Begin(BeginMode.TriangleStrip);

	GL.TexCoord2(64, 126);
	GL.Color4(1, 1, 1, 1);
	GL.Vertex3(-0.33544921875, -0.02392578125, 0.6279296875);

	GL.TexCoord2(64, 103);
	GL.Color4(1, 0.9354839, 0.8064516, 1);
	GL.Vertex3(-0.216064453125, 0.1953125, 0.508056640625);

	GL.TexCoord2(0, 126);
	GL.Color4(1, 1, 1, 1);
	GL.Vertex3(-0.906005859375, -0.02392578125, -0.225830078125);

	GL.TexCoord2(0, 103);
	GL.Color4(1, 0.9354839, 0.8064516, 1);
	GL.Vertex3(-0.649169921875, 0.48486328125, -0.098876953125);

GL.End();

GL.Begin(BeginMode.Quads);

	GL.TexCoord2(0, 0);
	GL.Vertex3(-0.39599609375, 1.484130859375, 0.197265625);

	GL.TexCoord2(0, 30);
	GL.Vertex3(0.037109375, 1.194580078125, 0.80419921875);

	GL.TexCoord2(64, 30);
	GL.Vertex3(0.6826171875, 1.1708984375, 0.332275390625);

	GL.TexCoord2(64, 0);
	GL.Vertex3(0.24951171875, 1.46044921875, -0.274658203125);

	GL.TexCoord2(64, 103);
	GL.Color4(0.5483871, 0.483871, 0.3548387, 1);
	GL.Vertex3(0.429443359375, 0.171630859375, 0.0361328125);

	GL.TexCoord2(64, 31);
	GL.Vertex3(0.6826171875, 1.1708984375, 0.332275390625);

	GL.TexCoord2(0, 31);
	GL.Vertex3(0.037109375, 1.194580078125, 0.80419921875);

	GL.TexCoord2(0, 103);
	GL.Vertex3(-0.216064453125, 0.1953125, 0.508056640625);

	GL.TexCoord2(64, 103);
	GL.Color4(0.4193548, 0.3225806, 0.1935484, 1);
	GL.Vertex3(-0.003662109375, 0.46142578125, -0.57080078125);

	GL.TexCoord2(64, 31);
	GL.Vertex3(0.24951171875, 1.46044921875, -0.274658203125);

	GL.TexCoord2(0, 31);
	GL.Vertex3(0.6826171875, 1.1708984375, 0.332275390625);

	GL.TexCoord2(0, 103);
	GL.Vertex3(0.429443359375, 0.171630859375, 0.0361328125);

	GL.TexCoord2(64, 103);
	GL.Color4(0.6774194, 0.6451613, 0.4516129, 1);
	GL.Vertex3(-0.649169921875, 0.48486328125, -0.098876953125);

	GL.TexCoord2(64, 31);
	GL.Vertex3(-0.39599609375, 1.484130859375, 0.197265625);

	GL.TexCoord2(0, 31);
	GL.Vertex3(0.24951171875, 1.46044921875, -0.274658203125);

	GL.TexCoord2(0, 103);
	GL.Vertex3(-0.003662109375, 0.46142578125, -0.57080078125);

	GL.TexCoord2(64, 103);
	GL.Color4(1, 0.9354839, 0.8064516, 1);
	GL.Vertex3(-0.216064453125, 0.1953125, 0.508056640625);

	GL.TexCoord2(64, 31);
	GL.Vertex3(0.037109375, 1.194580078125, 0.80419921875);

	GL.TexCoord2(0, 31);
	GL.Vertex3(-0.39599609375, 1.484130859375, 0.197265625);

	GL.TexCoord2(0, 103);
	GL.Vertex3(-0.649169921875, 0.48486328125, -0.098876953125);

GL.End();

/* 01_04 */
GL.Begin(BeginMode.TriangleStrip);

	GL.TexCoord2(129, 63);
	GL.Color4(0.7741935, 0.6774194, 0.3870968, 1);
	GL.Vertex3(0.04931640625, 1.4560546875, 0.03125);

	GL.TexCoord2(90, 63);
	GL.Vertex3(-0.642578125, 1.251953125, 0.22509765625);

	GL.TexCoord2(129, 1);
	GL.Color4(1, 0.9354839, 0.8064516, 1);
	GL.Vertex3(-0.25390625, 2.17236328125, -0.138427734375);

	GL.TexCoord2(90, 1);
	GL.Vertex3(-0.877197265625, 1.98291015625, 0.109130859375);

GL.End();

GL.Begin(BeginMode.TriangleStrip);

	GL.TexCoord2(129, 63);
	GL.Color4(0.7741935, 0.6774194, 0.3870968, 1);
	GL.Vertex3(-0.23828125, 1.457763671875, 0.598388671875);

	GL.TexCoord2(90, 63);
	GL.Vertex3(-0.47509765625, 1.256591796875, -0.076416015625);

	GL.TexCoord2(129, 1);
	GL.Color4(1, 0.9354839, 0.8064516, 1);
	GL.Vertex3(-0.430908203125, 2.21435546875, 0.245849609375);

	GL.TexCoord2(90, 1);
	GL.Vertex3(-0.65234375, 1.9013671875, -0.3896484375);

GL.End();

GL.Begin(BeginMode.TriangleStrip);

	GL.TexCoord2(90, 1);
	GL.Vertex3(-0.877197265625, 1.98291015625, 0.109130859375);

	GL.TexCoord2(90, 63);
	GL.Color4(0.7741935, 0.6774194, 0.3870968, 1);
	GL.Vertex3(-0.642578125, 1.251953125, 0.22509765625);

	GL.TexCoord2(129, 1);
	GL.Color4(1, 0.9354839, 0.8064516, 1);
	GL.Vertex3(-0.25390625, 2.17236328125, -0.138427734375);

	GL.TexCoord2(129, 63);
	GL.Color4(0.7741935, 0.6774194, 0.3870968, 1);
	GL.Vertex3(0.04931640625, 1.4560546875, 0.03125);

GL.End();

GL.Begin(BeginMode.TriangleStrip);

	GL.TexCoord2(90, 1);
	GL.Color4(1, 0.9354839, 0.8064516, 1);
	GL.Vertex3(-0.65234375, 1.9013671875, -0.3896484375);

	GL.TexCoord2(90, 63);
	GL.Color4(0.7741935, 0.6774194, 0.3870968, 1);
	GL.Vertex3(-0.47509765625, 1.256591796875, -0.076416015625);

	GL.TexCoord2(129, 1);
	GL.Color4(1, 0.9354839, 0.8064516, 1);
	GL.Vertex3(-0.430908203125, 2.21435546875, 0.245849609375);

	GL.TexCoord2(129, 63);
	GL.Color4(0.7741935, 0.6774194, 0.3870968, 1);
	GL.Vertex3(-0.23828125, 1.457763671875, 0.598388671875);

GL.End();

 

[haddockd]

I know I *should* know this but is this for Etrian Odyssey for DS?

[xdaniel]

It's basically supposed to become a port - or at least part of one, namely dungeon crawling and battles - of EO1 to the Dreamcast. Would be cool if I got it to a playable state - and then potentially add more elements to it, ex. from EO4 - not sure if it'll actually get there... At the very least it's a good learning project, ex. because of some "firsts" for me in this, such as using C++ instead of just plain C (although, well, it's really a mix of both).

 

EDIT: Model converter now makes ARGB4444 textures instead of ARGB1555, fixes broken alpha channels. Also made Frenda's model loader class compatible with textures of both types instead of just ARGB1555.

 

Edited October 29, 2013 by xdaniel

[xdaniel]

The return of the tonsillitis, complete with fever etc., got in the way of me working on this some more. That, and being nudged to work on cracking BLOCKS.bin from the Star Fox Adventures E3 demo, which did pay off at least (old Dinosaur Planet level data!).

 

Anyway, I decided to make converting textures, models, etc. a bit easier on me and finally make a proper converter for all this stuff. Up until now, I only had some separate, half-baked projects with hardcoded paths and such, them getting amended for many little things, etc., etc. Now, there's the work-in-progress "Frenda Multi Converter":

 

 

It's a command line application that takes bundles of arguments, such as t="E:\Translations\NDS Etrian Odyssey Hacking\i_opn_rogo01.ntft.png","C:\cygwin\home\Daniel\DCEO2\cddata\tex\title_logo.tex",RGBA5551 or f="Droid Sans Mono",24.0,true,"C:\cygwin\home\Daniel\DCEO2\cddata\fnt\debug.bin", and creates the proper converted files from them. It can also load those arguments from an external file, such as the resconv.txt from the screenshot, which contains two lines for font conversion. I believe it should even be able to load nested resource conversion script thingys, meaning you've got one text file containing a bunch of r=C:\cygwin\home\Daniel\DCEO2\<xxxx>.txt lines, which in turn each convert, say, the resources for one part of the game - one converts all dungeon models, another converts the title screen data, another does enemy images, etc.

 

Whew, hope that makes some sense, it's not really anything special, yet I tried to explain it in detail... or something. Gotta get back to work and add support for converting models next...

 

[xdaniel]

So having gotten back into SceneNavi development, and that bit of an argument with Airikita leading to R&D on a new F3DEX2 model converter, I've neglected Frenda/DCEO for the last two months. Still haven't actively worked on it again since, but I've been thinking about it a lot earlier today - ironically, while playing my never-finished/aborted PSX puzzle game project PanelFlip for 30 or so minutes.

This is basically a short to-do list for myself, but I figured some of you might be interested:

• Short-term: Change model format in Frenda again to support multiple models per file; should cut down on CD load time and filesizes
• Short-term: Finish texture, font, model conversion support in Multi Converter
• Short-term: Start "dungeon" gamestate; plan out floor data format, merge the respective original EO formats into one, implement manager class
• Longer-term: Add actual floor rendering, party movement to "dungeon" gamestate
• Longer-term: Start "battle" gamestate; plan out monster data and encounter group formats, etc.
• Longer-term: Change model format again OR create additional format for animated models <- requires more research into animations in original EO NSBMD model files

 

[Vexiant]

The return of the tonsillitis, complete with fever etc., got in the way of me working on this some more. That, and being nudged to work on cracking BLOCKS.bin from the Star Fox Adventures E3 demo, which did pay off at least (old Dinosaur Planet level data!).

 

Anyway, I decided to make converting textures, models, etc. a bit easier on me and finally make a proper converter for all this stuff. Up until now, I only had some separate, half-baked projects with hardcoded paths and such, them getting amended for many little things, etc., etc. Now, there's the work-in-progress "Frenda Multi Converter":

 

 

It's a command line application that takes bundles of arguments, such as t="E:\Translations\NDS Etrian Odyssey Hacking\i_opn_rogo01.ntft.png","C:\cygwin\home\Daniel\DCEO2\cddata\tex\title_logo.tex",RGBA5551 or f="Droid Sans Mono",24.0,true,"C:\cygwin\home\Daniel\DCEO2\cddata\fnt\debug.bin", and creates the proper converted files from them. It can also load those arguments from an external file, such as the resconv.txt from the screenshot, which contains two lines for font conversion. I believe it should even be able to load nested resource conversion script thingys, meaning you've got one text file containing a bunch of r=C:\cygwin\home\Daniel\DCEO2\<xxxx>.txt lines, which in turn each convert, say, the resources for one part of the game - one converts all dungeon models, another converts the title screen data, another does enemy images, etc.

 

Whew, hope that makes some sense, it's not really anything special, yet I tried to explain it in detail... or something. Gotta get back to work and add support for converting models next...

People don't appreciate you enough! What can you tell me about ZLB files besides them using zlib as well as LZO compression and starting on 32 byte boundaries? And what gives with the lack of headers? (If you don't mind or even know)

[xdaniel]

People don't appreciate you enough! What can you tell me about ZLB files besides them using zlib as well as LZO compression and starting on 32 byte boundaries? And what gives with the lack of headers? (If you don't mind or even know)

 

Star Fox Adventures, I presume? LZO files I have no idea about, ZLB files have headers as such: ZZZZZZZZ XXXXXXXX UUUUUUUU CCCCCCCC

• Z - 4 bytes: file tag/magic number (ASCII "ZLB" + null byte)
• X - 4 bytes: unknown, version number or something?
• U - 4 bytes: uncompressed length of data
• C - 4 bytes: compressed length of data
• [C bytes of compressed data follow, can be decompressed by zlib]

Header offsets are taken from the corresponding .tab file, not 100% sure about the .tab format (1st byte of offsets seems to determine if data is compressed?)

 

[xdaniel]

Super Happy Fun Random Junk Time!

 

 

 

 

...and in not so fun news, DCEO/Frenda's Model class seems to be leaking memory, and if it does, I have no bloody clue where. I've changed the model format, as mentioned before, to contain multiple models per file and have rewritten the class accordingly... but there seems to be something wrong with it, because (at least under emulation, not tried this in particular on hardware yet) this loop I've added for testing - which just loads one model file in, then unloads it the next frame, and moves onto the next file / loops back to the first when finished - causes the system to crash after a few thousand files (= constructor/destructor calls).

 

I dunno, I'm pretty sure I'm using new/delete properly, not leaving any memory allocated with new undeleted, etc., etc., but it still happens. I'll have to burn a CD I guess, and see how long it'll keep going on my Dreamcast...

[xdaniel]

After more combing through the Model class, the ModelViewer gamestate and the PVR setup parameters, and finally another round of hardware testing, I'm 99% sure that I've got the weird crashes isolated and "fixed". The aforementioned loop has been going through 22000+ models on my Dreamcast now with not a single crash. I haven't verified against emulation yet, tho, so I can't actually say if the changes I've done to the code (changed buffer sizes in PVR initialization, disabled BGM playback) are why it appears to work fine on hardware, or if it just was nullDC being nullDC the whole time (i.e. buggy).

 

Regardless, I'm probably going to conside the Model class fully functional now, so I'll probably get the dungeon gamestate started soon-ish. At least basic map management with some dummy map, the camera and party movement.

[xdaniel]

Slow progress is slow...

 

 

 

[haddockd]

I thought the dreamcast was a failed system that not many played. Am I wrong on that?

[xdaniel]

It was a commercial failure for various reasons - IIRC Sega's previous screw-ups with the Mega CD, 32X and Saturn not inciting confidence, people rather waiting for the PS2 and/or Sony stealing away any thunder the DC might've had or gotten, etc.

 

However, it is being held in high regard for, I guess, innovation and creativity (in great games, but also hardware features; ex. built-in support for online gaming), it was getting games in Japan up until early 2007, so after even the Wii had been released, there's still homebrew and indie games being made and sold for it today, such as what the NG-DEV-TEAM is making, etc. I guess... it's basically been appreciated much more and better long after it died its commercial death.

[Shadow Fire]

Another reason the DC failed commercially was due to the lack of third-party support. DC games were easy to copy and play due to the lack of any real copy-protection. As such, many third-party publishers opted to steer clear of the system. Except for Sonic Adventure, Sonic Adventure 2 and Virtua Fighter 3tb, every game I owned when I had the DC was a burned copy, or homebrew.

[Airikita]

They likely lacked knowledge on how to secure their game system from hacking and piracy... probably was something they should have hired someone to do before making a bunch of failed products. At least they make good Sonic games.

 

Anyways, I'm loving the textbox xDan.

[xdaniel]

The problem with copy protection on the DC was likely that Sega believed, the system's proprietary GD-ROM format was enough to prevent copies... which would have been the case if they hadn't included MIL-CD support in the system, which is what was abused for piracy. GD-ROMs cannot be burned by normal CD/DVD writers, writeable GDs aren't available to the general public - the only way to write an actual GD-ROM is by using an official GD writer and empty GD-R meant for development. So, hadn't it been for that MIL-CD stuff, piracy might not have happened on the DC, or at least not as soon as it did.

[Jason777]

My Dreamcast has always been my favorite console.

 

I think that some later Dreamcast's were made that disabled playing CD-Rs but by that time it was too late...

[xdaniel]

Message box seems stable, supports a few control codes for ex. text coloring. Substituted Droid Sans for the original DS firmware, and in turn European Etrian Odyssey, font... mainly for PVR memory reasons, as I keep running out of RAM on the PVR side... need to figure out why exactly that happens and what I can do about it.

 

 

 

dialog->setText(
	"One day, in the small, isolated{n}town of {cFFFF00}Etria{c}, an underground{n}forest was discovered.{p}"
	"{cFFFF00}The Radha{c}, govenors of Etria,{n}issued a proclamation throughout{n}the continent...{p}"
	"Any able-bodied adventurer was{n}invited to investigate the{n}forest and explore its depths.{p}"
	"But no matter how many came to{n}investigate the dungeon, none{n}gained the renown they sought.{p}"
	"As more adventurers tried and{n}failed to conquer it, it came{n}to be known by a new name...{p}"
	"{cFFFF00}The Yggdrasil Labyrinth{c}.{p}"
	"You are the latest adventurer{n}to journey to Etria in response{n}to the Radha's proclamation.{p}"
	"You have but one goal: explore{n}the forest to win fame and{n}fortune. Etria is at hand..."
	);