Language…
10 users online:  AmperSam, Anas, Cristian Cardoso, Golden Yoshi, Hayashi Neru, JezJitzu, mmmdoggy, nonamelol1, PMH, Sokobansolver - Guests: 254 - Bots: 449
Users: 64,795 (2,377 active)
Latest user: mathew

Posts by ExE Boss

ExE Boss's Profile → Posts

  • Pages:
  • 1
My layout has recently been updated, but you still have the old stylesheet cached and things might therefore not look as intended, as such, it’s recommended to reload the page.

Right now, the contact info is visible to anyone who is registered and logged in on this site.

In case of the e-mail, it is necessary for it to be set to make password resets progress more smoothly, but at the same time, some people really don’t want any random person to be able to just look up their e-mail.

As a solution, I propose that an option with the following contact info visibility settings gets added to each contact info field:

  • Registered users - The current setting
  • Private - Only visible to the account owner and admins

My layout has recently been updated, but you still have the old stylesheet cached and things might therefore not look as intended, as such, it’s recommended to reload the page.
At the very least, it should be possible to hide the e-mail field.
My layout has recently been updated, but you still have the old stylesheet cached and things might therefore not look as intended, as such, it’s recommended to reload the page.
As the readme.txt file says, we’re supposed to notify you when the converted patches site link has expired, which it has now. To permanently resolve issues with Dropbox expiring, I would suggest hosting the files in a GitHub Pages project site, this way, the links won’t keep expiring from Dropbox.
My layout has recently been updated, but you still have the old stylesheet cached and things might therefore not look as intended, as such, it’s recommended to reload the page.

I discovered the Overworld music data completely accidentally while writing my Core Dump (BRK Interrupt Vector) Patch, which I will be releasing very soon. Update: It’s out now.

The Overworld and Title Screen use the following registers with the following values:

$7E:1DFB - Music Register
  $01 - Title Screen
  $02 - Overworld
  $03 - Yoshi’s Island
  $04 - Vanilla Dome
  $05 - Star Road
  $06 - Forest of Illusion
  $07 - Valley of Bowser
  $08 - Bowser’s Valley Appears/Earthquake Sequence (SFX)
  $09 - Special World (incidentally, this is the reason why dying on the Title Screen causes Special World music to play)

The other registers seem to be the same.

My layout has recently been updated, but you still have the old stylesheet cached and things might therefore not look as intended, as such, it’s recommended to reload the page.
I would like to see more of Dynamic Z’s features.
My layout has recently been updated, but you still have the old stylesheet cached and things might therefore not look as intended, as such, it’s recommended to reload the page.
Originally posted by telinc1
Let me show you why I think GIEPY is a good choice by giving you a list of things it does better than SpriteTool and/or PIXI:
  • Extra bits. GIEPY completely removes the concept of the extra bit.

Well, Tessera did this way back in 2013, but sadly, it didn’t end up being used much at all.

Originally posted by telinc1
  • CFG editor. This is the first big problem. The creation of a new CFG editor is essential. Being the perfectionist I am, it would also be nice to make it an all-in-one tool which can also edit vanilla sprites (a la Tweaker). I am willing to create this editor myself but the best language I could program it with is Java since I don’t know any language which would be potentially more suitable. While this does mean it will be cross-platform, running it will require you to have the JRE installed (aside from all of Java’s quirks like a long start-up time). If anyone else is willing to create this editor in a language which is more suitable for the job (like C# or Qt with C++), please do say.

Java is a pretty good language for this in my opinion.

My layout has recently been updated, but you still have the old stylesheet cached and things might therefore not look as intended, as such, it’s recommended to reload the page.

On the topic of JSON extensions, there’s also JSON5 and Lightbend’s HOCON, with HOCON being rather similar to YAML but without the no tabs allowed BS.

Personally, I’m in favour of using HOCON over YAML, because I dislike YAML for the no tabs rule BS.

My layout has recently been updated, but you still have the old stylesheet cached and things might therefore not look as intended, as such, it’s recommended to reload the page.
Originally posted by GreenHammerBro
Originally posted by leod
But tabs are always the same width on every person’s individual editor of choice, so I’m not sure how it would differ from spaces... Whether there’s 2 spaces per level of indent or a tab looking 2/4/8 spaces, the indentation level will always be clearly readable on all ends, while keeping the person’s personal preference of indentation width intact.
Notepad++ have a tab with of 5 (not exactly sure what is the tab width). However you can change that by going into Settings -> Preferences -> Language and on tab size. Set that to 8.

Actually, Notepad++ has a default tab width of 4. (Seriously, who uses tab widths that are not a power of 2?)

Originally posted by RPG Hacker
I think leod’s point is that tab width doesn’t even matter as long as you don’t mix tabs with spaces in your document. Indentations will be consistent as long as you use only tabs or only spaces.

This is also the reason why Python allows both spaces and tabs, despite being about as sensitive about whitespace as YAML, because as long as you are consistent with your whitespace, everything will work out just fine.


P.S.: Elastic tabstops are just another advantage of tabs over spaces.

My layout has recently been updated, but you still have the old stylesheet cached and things might therefore not look as intended, as such, it’s recommended to reload the page.

Looks and feels pretty good, but why is the layout* handled using tables instead of CSS like my website or the VWF Dialogues Patch V1.2 Readme?

*Note: When I say layout, I mean why does <body> contain a single <table> element which is then used to lay out the entire page? It’s terrible for responsive design.

List of reasons why using <table>s for design is terrible:


P.S.: I can try to fix that <table> mess if the source is available on GitHub.

My layout has recently been updated, but you still have the old stylesheet cached and things might therefore not look as intended, as such, it’s recommended to reload the page.
Can you please put the source code of the patch on your GitHub so that I can contribute my changes to it, or should I just stick it in my SMW workspace and contribute the changes to it that way?
My layout has recently been updated, but you still have the old stylesheet cached and things might therefore not look as intended, as such, it’s recommended to reload the page.
Originally posted by Ladida
what did you do to it o_O

I increased the maximum available amount of GFX slots to 256 and made it a SA-1 hybrid patch using RPGHacker’s shared functions.

Originally posted by Ladida
assuming i put it on github: is there a specific format/etc you want everything in? aka necessary files, folders, etc)

Using the layout of RPGHacker’s or my SMW workspace would be nice, as it would make it easier for me to add the improvements easily, as they depend on RPGHacker’s shared functions.

My layout has recently been updated, but you still have the old stylesheet cached and things might therefore not look as intended, as such, it’s recommended to reload the page.

Dear Kieran,

I would like to request for the new memory map frontend code to be made open source and published to GitHub so that the community can contribute features and fixes to it.

Sincerely,
ExE Boss

P.S.: I’m attaching the relevant Discord Server logs and quoting the relevant posts from the Memory Map Announcement Thread that led to the creation of this forum post (I would put them inside a <details> element, but the forum doesn’t allow HTML5 #tb{:(}):

Mod edit: Moved the discord logs to pastebin.

Originally posted by ExE Boss

Looks and feels pretty good, but why is the layout* handled using tables instead of CSS like my website or the VWF Dialogues Patch V1.2 Readme?

*Note: When I say layout, I mean why does <body> contain a single <table> element which is then used to lay out the entire page? It’s terrible for responsive design.

List of reasons why using <table>s for design is terrible:


P.S.: I can try to fix that <table> mess if the source is available on GitHub.

Originally posted by randomdude999
It uses tables because the layout is a copy of the rain theme, which was either created ages ago when tables where still a common way to do layouts or it just copied the HTML code from a different layout (maybe the default one, which seems to be mostly unedited for like a decade) and changed stuff until it looked good. Go complain in the site questions forum about the tables.
Originally posted by telinc1
What randomdude999 said. The webpage I linked to is just a demonstration version. From the very beginning, I had planned to actually integrate it into SMW Central, not keep it a separate website.

If you take a closer look at the source code, most of the layout is directly copy-pasted from SMW Central and uses a mostly unmodified version of rain.css, which is the Rain scheme you can select from Edit Profile. Doing it properly would make no sense in this case because I'd either need to convert it into tables or make custom CSS for every possible site scheme.

As for why SMW Central uses a table-based design, it's because it was created years ago, back when Internet Explorer 6 was the standard browser and tables were pretty much the only way to position anything. Today, it looks quite dated, but still works.

By the way, I wouldn't need help to create anything without using tables. After all, most web designers can do that.
My layout has recently been updated, but you still have the old stylesheet cached and things might therefore not look as intended, as such, it’s recommended to reload the page.
Originally posted by Teyla
Those quotes explain it pretty succinctly to me. The map is supposed to be integrated with the site, which is also built out of tables. Therefore, to keep proper compatibility, you would use the same thing.

I don't see a problem with it? If the site was modern I'm sure the memory map would've been developed to match.

This isn’t really about the tables, this is about open sourcing the project so that features like displaying the (SA-1) suffix after SA-1 addresses, as has been suggested by randomdude999[1], can be contributed by the community, which would make development faster, as it wouldn’t be just telinc1 working on it.


Footnote 1
[17:19] randomdude999: could you add "(SA-1)" to the end of the description for the remapped tables?
My layout has recently been updated, but you still have the old stylesheet cached and things might therefore not look as intended, as such, it’s recommended to reload the page.
I’ve now submitted version 1.2 for moderation and uploaded the source code to my GitHub.
My layout has recently been updated, but you still have the old stylesheet cached and things might therefore not look as intended, as such, it’s recommended to reload the page.
Originally posted by Kaijyuu
Originally posted by Ladida
use a fake crash instead. literally the same thing for the end-user, but it wont potentially break the system/emulator
This seems reasonable to me. Not too hard to fill the screen with garbage and then maybe print "crash lol".
You could probably use my Core Dump Patch as a base for that.
My layout has recently been updated, but you still have the old stylesheet cached and things might therefore not look as intended, as such, it’s recommended to reload the page.

Mega Bump 2: Electric Boogaloo!

With the help of me, randomdude999 and RPG Hacker, VWF Dialogues version v1.2 has now been submitted for moderation and uploaded to RPG Hacker’s GitHub repository.

Version 1.2 major changes:

  • Converted to a SA‑1 hybrid patch.
  • Completely overhauled the Readme - it now looks nicer and some of the outdated information in it was updated (it’s called the Manual now).
  • The patch now uses a coding style that’s more in-line with RPG Hacker’s other patches - most configurable settings are now in vwfconfig.cfg.
  • Randomdude999 added a Python script for generating width tables.
  • Bug fixes and improvements… (see the version 1.2 changelog in the Manual for details)
My layout has recently been updated, but you still have the old stylesheet cached and things might therefore not look as intended, as such, it’s recommended to reload the page.
Originally posted by FuSoYa
Originally posted by Deeke

Could we have a toggle that highlights/hides tiles depending on if they have priority enabled or not?

It's not really much trouble with vanilla World, but trying to find rogue tiles that look similar but have different priority with custom graphics can be a headache.

How often does that come up though?

Quite a bit if you’re using custom overworld graphics.

My layout has recently been updated, but you still have the old stylesheet cached and things might therefore not look as intended, as such, it’s recommended to reload the page.

Hyper‑Bump Re;Birth

With my help, version 1.3 of this patch is being implemented on the GitHub repository and is currently in beta.

Version 1.3 major changes:

  • Converted to a SA‑1 hybrid patch.
  • The patch now uses a coding style that’s more in-line with RPG Hacker’s other patches - most configurable settings are now in hpconfig.cfg.
  • Bug fixes and improvements… (see the version 1.3 changelog in the linked GitHub repository for details)

There are still a few bugs left to fix before RPG Hacker will be releasing version 1.3 to SMW Central.

My layout has recently been updated, but you still have the old stylesheet cached and things might therefore not look as intended, as such, it’s recommended to reload the page.
Originally posted by Vitor Vilela

As you might know, SA-1 and SNES communicates though IRQs and when the SA-1 CPU needs to do a certain operation such as storing to WRAM ($7E-$7F), communicating to PPU or any other SNES-side thing, the chip needs to send an IRQ request to SNES and then the S-CPU does what the SA-1 asked for. It's the best method for fast communicating with the both CPUs and warrants full code compatibility between them because if there is something that the S-CPU or SA-1 CPU can't do, it gently asks one of them to do the task though IRQs.

IRQs are also used to communicate between the S-CPU and S-PPU. S-PPU, for example, sends an NMI (which is a non-interruptable IRQ) to the SNES at end of each frame. There's also the V-IRQ, H-IRQ and HV-IRQ whcih are IRQs generated when a certain position of the H-/V- counters reach a certain value. The most classic example is the Status Bar IRQ, that the S-CPU receives at around V-Count = 36 and then the S-CPU does mid-scanline writes (yes, exactly) to change the layer 3 x/y positions, current mode, some cgadsub addresses and a little more, depending if it's a mode 7 fight or not.

ZSNES thought it was a good idea to implement all IRQs in the same way. As well H-DMA and H-Blanks. Looking at the ZSNES source code, on the SA-1 part (sa1proc.asm, sa1regs.asm), when the CPU generates an IRQ simply a flag is set and nothing else. What makes the IRQ actually occur is on the file execute.asm and there you can see a huge fuzz x86 mess code which checks for every single possible IRQ and starts generating them depending on the occasion. However, when a certain interrupt request is received, ZSNES just sets it and leaves the routine. So it literally forgets everything else. Because of that, when SA-1 sends an IRQ to the SNES CPU, if it's triggered nearby H-blank, all HDMAs are automatically cancelled because ZSNES just "forgets" to execute them. And on the next scanline the HDMA is executed normally, except that everything will be shifted down by one scanline now.

For the next version of SA-1 Pack I'm currently working, I'm completely rewriting the IRQ and NMI routines. And I have attempted to make my IRQs give absolute priority to the PPU IRQs and only later check for SA-1 IRQs. So the risks of eventual scanline glitching would be avoided, which includes real hardware. Especially when there's HDMA involved.

However, ZSNES simply didn't work with the new IRQ controller. Once an IRQ is called, ZSNES does not clear the IRQ flags correctly and there is no way to know when an IRQ was generated by the PPU. Only by the SA-1. Because of that I had to write a custom IRQ controller just for ZSNES and still with all ZSNES-related-hacks that certainly would break other real hardware, it still keeps with that particular glitching. So sadly, I think I have done the maximum possible and the only way to avoid that is simply removing all SA-1 IRQs from the patch and reallocate some of the routines back to the SNES CPU just for better ZSNES compatibility. I might do that as well for the next version.

But don't get surprised: many games like to flicker on the ZSNES. Yoshi's Island Mode 2 levels are a nice example. VLDC9 overworld also has a lot of flickering on ZSNES, for the same reason (poor IRQ implementation).

I’d personally just drop supporting ZSNES at this point[1].


Footnote 1
I did the same with Internet Explorer on my website.
My layout has recently been updated, but you still have the old stylesheet cached and things might therefore not look as intended, as such, it’s recommended to reload the page.

I pretty much agree with what RPG Hacker said, especially with this:

Originally posted by RPG Hacker
Originally posted by Vitor Vilela

I don't see myself adding a configuration file on SA-1 Pack for example because the only two options the patch offers is enabling/disabling ZSNES support and DSX. Usually people don't change those settings without knowing what they're doing.

That's a good point you brought up here, and one that I completely forgot to think about, despite it actually being relevant to one of my patches. I kinda forgot about this, but my VWF patch doesn't actually expose all of its defines in its .cfg file, only the ones that could reasonably make sense to be changed by average users/non-coders. It does have tons of other defines, but those remain in the .asm file as they're really meaningless to people who aren't trying to directly modify the patch or just aren't familiar with coding. IMO, this split actually makes sense and is a good idea. It's one case where I actually support putting into the .asm file. My .cfg file, as the extension implies, is really intended as a configuration file (or a setting file, if you will), influencing the patch's behavior, and it really only makes sense to expose this as a separate file if it can be reasonably assumed that it could make sense for average users to change this. IMO, this is a way more important distinction than saying "if we only have X defines, they go into the .asm file, if we have more than that, they go into an external file with whatever extension". If your patch only uses a single define and this define only really makse sense to modify if you're familiar with code, then sure, put it directly into the .asm file. However, if your code contains settings that make sense to be modifyable even by average users or novice programmers, then put it into a separate file, even if it's just a single define.

I personally am in favour of using the .cfg file extension, but that’s because I have it intuitively associated with “Generic configuration file” in my head.

As for $deadbeef|!base1 vs remap_ram($deadbeef), I personally prefer the latter, mainly because the remap_ram function handles all RAM addresses (including SRAM, the sprite tables and Wiggler data), which the usage of the |!base1 define won’t handle correctly.

  • Pages:
  • 1