BlogGL

Life is always a balance between what’s ideal, practical, and what resources are available. Even is something isn’t fesable, it can still help you figure out what your priorities are, and then think of how to better manage what you have.

Screen: Cintiq 27QHD
Case: DA2
Motherboard: GIGABYTE B450 I AORUS PRO
CPU: AMD CPU Ryzen 5 2600
Memory: Corsair DDR4 16GBx2
Storage: Crucial 1TB Nvme
Graphics: MSI Radeon Vega 56

A few things to note. QHD on the monitor is a must. But getting a 27″ wacom monitor is spending a massive amount of money when the 22″ and 13″ versions are signiticantly cheaper. So it could be an idea to use a QHD, or 4k monitor as a main display, and then a 13″ tablet as a side drawing option.

As for the computer, it’s basically build around the case. The Dan case is a pretty beautiful looking mini-itx case. But then I really don’t like having to shop around for a graphics card and power supply. And with the Gigabyte mother board, it makes a graphics card a lot less necessary with two hdmi out directly on the board with options like the 2400G. Something like the Udoo Bolt would more than cover my use case.

Edit: Though for the sake of argument, I could go with the MSI Motherboard, and that would give me an excuse for having a graphics card.

I’m getting really close to when I need to be moving. And the most important part of about moving is (of course), planning out all of my stupid little hardware projects.

So one set back to my fever dreams of making hardware designs is that my tinkering with the Raspberry Pi on the desktop build ruined something and now the Pi won’t boot. So I think I’ll put off the delusions of granduer, for fleshing out these ideas in real life in exchange for drafting them on paper.

The functionality for what I want can be accomplished pretty easily. So I’ll buy the few parts I need, and then focus on software. I’ve made pages for the hardware designs, to keep track of all of the infortmation, parts, and to keep track of similar projects.

One thing that surprised me, is the setup for the PiBoy Advance setup is super simple, only requiring an LCD and an SNES controller, that I don’t think I need to use a Raspberry Pi as a desktop. So I’m still tempted to go for usb everything. But I have the option of continuing to use a notebook. Or I can probably manage to grab some screens and computers from work to set something up.

I think I’m tempted to borrow two monitors from work, and then set up Fedora on my Asus mini-itx. And then set up CentOS on my other mini-itx and then use that as a project hosting computer.

I’m in this weird place, where there’s so much to do and it’s hard to figure out exactly where to start from.

Sealos Islands collision hulls was a fun side venture. The later maps get more time consuming. I would like to come back to this, but for now it’s a low priority. There is a lot more focus and need for the first Megaman Legends, and the amount of time put into making something one-off like this might as well be spent towards the first Megaman Legends game.

Dash Interchange Format, the main problem with this is the pointers needed in the archive sections. If I take my time and track the file position on paper, then I think I can get through this. I should try and prioritize finishing this when I get a chance.

Hardware designs are fun, but I think something better will come out by the time I ever get anything viable. I think I’ll stick to buying what parts are available to get as close as possible to the functionality I want. I’ll post the designs (that any idiot could think of) as pages to leave a record. And then I think I can use some kind of board, to screw down the parts, so that the functionality for each of the designs is grouped in someway rather than the parts being all over the place.

It’s been a lot easier finding information for C and SDL after switching to DuckDuckGo for some reason. And I think I’m a lot for familiar with the concepts to be able to start using it now. For tutorials, I want to see if I can make a brickout clone using SDL and OpenGL 1.0. And then port my astroids and invader clones to Opengl 2.0 (which they were intended for). After that I want to make a basic top down, and a basic side scroller (and I mean extremely basic). From there use OpenGL 2.0 for displaying a basic cube. And then OpenGL 3.0 for anything involving a model.

For Megaman Legends 2, I’ll see what I can do to help Xinus track down the ST39 problem. No promises, but I’ll try to budget a week and see what I can come up with. After that I really want to get back into debugging levels to see what I can come up with. And hopefully I’ll be able to ask Trege what he knows on Discord to be able to see if that matches up with what’s in the file.

So basically right now, help Xinus, work on Dash Interchange format and then stages.

Edit : Two more quick notes that don’t deserve their own posts. One is that I feel better about buying an previous generation AMD A-series APU. And the reason being is when I bought it, the AM4 platform was still pretty expensive. And either way it would just be sitting around in my apartment since I don’t have enough room to put a desktop computer. And then also, I need to start thinking about designs for DashGL.com and format.DashGL.com if I’m going to be updating them with new content.

PSP’s are stupid cheap, and it seems like it might be worth picking up a PSP for looking into game formats. Specifically with respect to Rockman Dash, and Phantasy Star Portable. But we’ll see, my budget for picking up new technology is wearing thin at the end of the year.

Likewise though, the PS Vita is now stupidly cheap, as it looks like Sony has done everything they possibly can to kill it. And I have my opinions about the Vita as well (mostly negative), as there are just so many stupid design decisions that were made before the device was even released. It seems like Sony was doing too much to try and appeal to casual cell phone players, who had no need to go out of their way to buy a gamin device. So it would have made a lot more sense for Sony to have simply made a compelling gaming device, at a lower price point, without all of the stupid gimmicks.

Though for the price, the open firmware, and the open source SDK, it seems like it would be a fun device to get my hands on and see what’s it’s capable off. But then again, if I’m spending money on something stupid, I could probably spend the same money on a Raspberry Pi kit on something. So I’ll probably have to give the Vita a pass since it fails in the memory format and proprietary usb cable. So I guess tempting, but not compelling enough to warrant buying.

I hate a love/hate relationship with cell phones. Mostly I dislike them and would probably be a lot better off ordering a Librem 5 and not looking back. But I like Lineage OS, and I especially like the fact that you can buy old Android phones, and then flash them to have an extremely light version of Lineage OS running. And then only install FOSS software on top of that. So there are a lot of phones I would like to get my hands on to see how the experience works out.

Google

• Nexus 4
• Nexus 5
• Nexus 5X
• Google Pixel

On the Google side of things we have the Nexus 4, Nexus 5, Nexus 5X and Google Pixel. I’ve been using the Nexus 5 for the last few years, and aside from the terrible camera, and terrible reliability, it’s actually a pretty good phone at the core. Though I had a phone where the microphone didn’t work, one died from an official update, one of them the battery would only last a few hours. So in general two out of three of the Nexus 5’s that I’ve bought in total have failed on me in some way. So it’s hard to recommend them to someone. So I’m skeptical about the Nexus 4, which is only on here because there are no small form factor cell phones any more, and they are dirt cheap, so it would be interesting to get one for testing and to see how it works. And while I haven’t had much luck with the Nexus 5, the Nexus 5x comes with a better camera and usb, so it would be interesting to get my hands on the actual device. For the Pixel, it just arrived a few days ago from ali express, and I haven’t spent much time with it yet.

Samsung

• Galaxy S3
• Galaxy S4 Mini
• Galaxy S6
• Galaxy S9

For the Samsung side, the S3 probably isn’t needed, but it’s actually been on my want list for a long time. So it would still be interesting to test if I can get my hands on one. The Galaxy S4 mini, because it’s a form factor that’s not often used. And in my case I mostly use my phone for music, and the occasional picture or text message. The Galaxy S6 is fairly recent, but is getting pretty cheap now with how cell phones develop. And it comes with a pretty decent camera and wireless charging. And lastly the Galaxy S9, which doens’t look like it should be on this list, as I would normally just want a S7. But the S7 still comes with a micro usb, which is totally stupid. And the S8 doesn’t support Linux. So most recent Samsung phone to support Lineage OS and have a usb-c charging port is the S9, which is stupidly expensive, but maybe someday.

Summary

Not sure if it’s actually worth it, since I could probably just order another Pixel if I ever needed a phone, since it pretty much out ranks the other phones on the list (outside of the S9), while not costing very much. So it depends on how much I actually want to invest in hardware that’s just going to sit in a drawer. But quick note, the Nexus 4 and Nexus 5x, I can probably pick up on amazon, while the samsung phones will probably require me to order them from ali-express.

Edit

Prices on the Nexus 4 aren’t as dirt cheap as they were. So with the Galaxy S4 mini probably being a better built phone with more reliable specs at a similar price, it makes owning this phone a lot less of a must have. But it would still be interesting to get the Nexus 4, assuming there was a decent deal on it.

So back of the napkin style, file layout planning. At the top of the file will be the magic number, version number, offset to the table of contents, and length of file. Though for the length, it’s the length of the file from the start of the table of contents, until the end of the file, not including the magic number and copyright, meta information. The meta information is located in-between the offset declared after the magic number. In general, this is not needed, so it could be located right after the first line in the file, but at the very least the file definition and export tool should be listed in this area. And in the case of copyright, the creator should declare what rights they intend for their creation in the file, to avoid confusion.

After that comes the table of contents with the number, offset and length. So the first offset from the images should come right after the table of contents (if exists). Otherwise the offset from the first material will come right after the table of contents.

Which means I need to start planning out the exporter for a Threejs plugin. So The first step will be to create a constructor for the exporter. The next step will be to create a parse function that accepts parameters for the author and copyright. The next step will be to break down the images, textures and materials into structs and then write the images, textures and structs. Since I have the base from the first version of the Dash Model Exporter, so I can take notes from my original exporter. And the last thing is in the case of Threejs, I should probably use Buffer Geometry and not normal geometry, because it’s easy to convert normal geometry to buffer geometry, and then break down the attributes into the specific lists.

To make things simple, I think I can use a fixed struct for the animation data. To put it simply:

typedef struct DashKeyFrame {
int frame;
int bone_id;
int parent_bone_id;
char use_position;
char use_rotation;
char use_scale;
char nop;
vec3 position;
vec3 rotation;
vec3 scale;
}

I think the above struct will allow me to use a fixed struct for each keyframe. Since for every frame, and every bone we need to have a transformation matrix to tell the mesh how to deform. But with the use of interpolation it means there are a lot of values that get automatically get filled in. And we can’t make the complete assumptions about just filling in all of the keyframes, otherwise the data that gets saved into the file and read from the file becomes drastically different. Also in a lot of cases the use of nested arrays is used to manage this information, and even though it’s redundant, just including the frame number, bone id and bone parent id in each keyframe removes the need to use any kind of nested structure in the data.

As for the character boolean values, we have one value that tells the importer to use position or not, rotation or not and scale or not. The effect of this is that there can be alot of data with default zero values are included in the data, but in this case simplicity and a fixed structure take priority, so I won’t lose much sleep if a few extra bytes is included here or there. The one weird part about all of this is the frames per second value, which I figured I might as well include as the fourth byte, otherwise it’s just a no operation byte anyways. So while I’m okay with wasting bytes for the sake of having a fixed struct, we also might as well use bytes that aren’t really being used for anything. I think this makes a change to the animation entry.

typedef struct DashAnimationEntry {
char animation_name[0x20];
unsigned int animation_id;
unsigned int offset;
unsigned int offset;
unsigned int number_of_keyframes;
unsigned int frames_per_second;
unsigned int number_of_frames;
unsigned int nop[2];
}

So I end up adding two nop values to the end of the animation entry, and then one nop into the keyframe values. But I guess that’s acceptable.