This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
What do you mean by different locations? As in, while decompressing it can write a byte at 0x0100, then next, instead of writing to 0x0101, it writes to 0x0150 or something like that? Because I'm pretty sure it writes them all consecutively, at least it looks that way, not sure how I would check whether there happens to be a byte that is written somewhere else.In terms of code it means that it writes decompressed data to two buffers: destination and a ring buffer. The latter is also used as source for compressed pairs.
It's definitely something along those lines, but I'm just wondering about the specific choice of the word 'beanpot'. Nearly every demonology source I could find (both primary and secondary) only ever seem to link Ukobach with 'pots', 'cauldrons' and 'boilers' specifically, although these differences in terminology could almost certainly be chalked up to the Dictionnaire Infernal's translation from its original French. The copy I found on archive.org from 1863 uses the word chaudière, which directly translates as roughly 'boiler' or 'kettle', but can also apparently be used to describe any sort of vessel that is specifically used to heat liquids (like a cauldron for example, especially in older contexts like fairy tales). The kanji '釜' also appears to read in a similar fashion, with 'kettle', 'iron pot' and 'cauldron' also invariably turning up when consulting several online dictionaries.I don't remember the specific source from where I got the beanpot reference (it's been almost 10 years now), but to Asian culture it's literally an infernal caldron like the following:
I did not quite understood this post.Many games suggesting this:
It was simply the absence of any high-range lights or darks that made me thing the effect looked 'mechanically batch processed' rather than hand selected.Nope, it's definitively a manual selection of color. See this:
The original colors aren't really an artistic choice, they look more like the result of a bad color converter.Nah, they are an actual artistic choice to make a pastel palette.
Hopefully the prerendered battle font doesn't use every little bit of VRAM left? I was hoping to increase the amount used for background graphics at least a little bit...
Has anyone else tried it?Which ROM are you using? Lenophis did some tests with the xdelta and it's working fine on his end too.
May I ask you, what font format are you using? Is it something standard like Square Font, or something home-brew?Not sure what's a Square Font, but I'm using raw 2bpp fonts for almost everything. They're fast and require no extra code for proportional rendering.
Also I'm interested in some technical details about implementation, like how many tiles are you using to render a page, what are the limitations, maybe share some difficulties ...
Well... you got Defend to finally be right. The rest of that is... a place I've never looked. I assume at leave 7-8 routines draw characters to the separate menus depending on context. That has always been a bit beyond me, so best of luck!
I looked into how to hack those menus for Tomato.Defend, Change, and MP needed use 4bpp graphics derived from the actual 2bpp font since they are displayed on BG2. What I did there was replace the upscale + DMA transfer with actual 4bpp graphics. Finding tilemaps was a bit of a mess because battle code tends to use completely different conventions. I'm still struggling with just rendering the other strings.
I recall those menus used their own font basically with their own font encoding.
Shouldn't be that hard to make the window text-length-dependent.The way I currently set it up makes that a bit complicated, but it also makes location windows behave similarly to their counteparts on GBA (which is what I was aiming for).
Just a thought - take it or leave it.