HighResEaser 1.7

[NES_player4LIFE]

Would you like the hard files also?
No prob I did edit the post maybe the site didn't refresh in time.

I've now completely fixed the bug from original HRE in a somewhat unorthodox way.

What bug is this again?

 

[CCTEX]

Would you like the hard files also?
No prob I did edit the post maybe the site didn't refresh in time.


What bug is this again?

@ NES_player4LIFE

Hard files?

It's a bug from microdev's 1.4 caused by photoshop not copying entire pixel selection to clipboard, only pixels that have a color value. My workaround in the end was to fill the top left and bottom right pixel of each loaded texture with RGB 0,0,0, Opacity 1. Invisible to the naked eye, but forces photoshop to copy the transparent space, thus fixing the glitch. Here's the added code:

	//CCBUGFIX
    	selectedRegion = Array(Array(texture.width-1,texture.height-1), Array(texture.width-1, texture.height), Array(texture.width, texture.height), Array(texture.width, texture.height-1));
    	texture.selection.select(selectedRegion);
    	texture.selection.fill(textColor,ColorBlendMode.NORMAL,1);
    	texture.selection.deselect();
    	
    	selectedRegion = Array(Array(0,0), Array(0,1), Array(1,1), Array(1, 0));
    	texture.selection.select(selectedRegion);
    	texture.selection.fill(textColor,ColorBlendMode.NORMAL,1);
    	texture.selection.deselect();
    	//CCBUGFIX

And here's the difference in how the new code loads the raw textures, notice not only was there a cutoff, but distortion as well:

vs

 

[NES_player4LIFE]

Hard file/Textures. Anyhow they are now located in the Space Invaders issue post.
Oh, that, thanks man!

 

[CCTEX]

Hard file/Textures. Anyhow they are now located in the Space Invaders issue post.
Oh, that, thanks man!

No problem [MENTION=29958]NES_player4LIFE[/MENTION]. And now, I give you.... (drum roll) full support for backgrounds/titles with multiple textures per row, up to 999! :king:

 

[NES_player4LIFE]

Thanks!

Where you able to migrate those 76PX?

 

[CCTEX]

Are you talking about the column that appears more narrow in my colored tile screenshot? I don't know what you mean by migrate, but the way I programmed the new ROBOREAD function, it handles this screenshot perfectly, the only extra question it asks the user is how many tiles per row. It used to ask for a fixed pixel offset, now it asks it as a percentage of relative tile width, (default is 50% and there was no need to change it for this example, despite the varying column width, so there'll probably rarely be a need to enter a different value). It then processes automatically and loads the actual textures as shown above. If you want to add artwork instead of upscale, then do this:

 

[NES_player4LIFE]

This is an old issue and is not related to your work.
I was just wondering if you had any insight on the issue.
Maybe it's how the files are dumped with Glide/Rice.

Anyhow the black line belongs to the edge but somehow Rice dumps it to the wrong textures.
That being said I don't think you will be able to fix it. Sorry for asking as it is really not a big deal.

It used to ask for a fixed pixel offset, now it asks it as a percentage of relative tile width

That great! can't wait for 1.7

 

[CCTEX]

This is an old issue and is not related to your work.
I was just wondering if you had any insight on the issue.
Maybe it's how the files are dumped with Glide/Rice.

Anyhow the black line belongs to the edge but somehow Rice dumps it to the wrong textures.
That being said I don't think you will be able to fix it. Sorry for asking as it is really not a big deal.


That great! can't wait for 1.7

Ahh, I see. I just accepted it was a game-specific idiosyncrasy like the MK64 BG textures having the right 30% filled with garbled nonsense. The workaround, if you're creating original hi res artwork, is to just logically overlay it where you can see it should go, like the dolphin example above. Good thing about upscaling is you don't need to worry about any of it. I upscaled the Activision textures with 1.7+Photozoom, black gap and all, and it appeared perfectly in the emulator.

 

[NES_player4LIFE]

Ahh, I see. I just accepted it was a game-specific idiosyncrasy like the MK64 BG textures having the right 30% filled with garbled nonsense. The workaround, if you're creating original hi res artwork, is to just logically overlay it where you can see it should go, like the dolphin example above. Good thing about upscaling is you don't need to worry about any of it. I upscaled the Activision textures with 1.7+Photozoom, black gap and all, and it appeared perfectly in the emulator.

Ok, Thanks. I just don't want to pester you with all these bugs.
I do enjoy not having to worry.

Tell me where did you learn to code?

 

[CCTEX]

No need for apology, I"m a perfectionist with stuff like this, if its a bug within my power to fix, i always want to know.

As far as coding, I taught myself, I'm actually a musician, I just pretend to be a programmer!

I've finished everything I wanted to accomplish with 1.7, including even random stuff I was too lazy to do before, like user input error handling, as well as some worst case scenario improbable bug scenarios. I don't want to fragment the top of the thread anymore, so let me know if there's any feature you can think of that's worth implementing before I release it.

 

[NES_player4LIFE]

No need for apology, I"m a perfectionist with stuff like this, if its a bug within my power to fix, i always want to know.

Good to hear. We need more members like you.

I just pretend to be a programmer!

You play make believe very well.

I've finished everything I wanted to accomplish with 1.7, including even random stuff I was too lazy to do before, like user input error handling, as well as some worst case scenario improbable bug scenarios. I don't want to fragment the top of the thread anymore, so let me know if there's any feature you can think of that's worth implementing before I release it.

It is quite a mess up there but I can give you another post if you would like. Post #3 is the download location now but I could bump it down to #4. if you would like.
As far a any other improvements I'm sure there are countless possibilities. Heck, you have already done so much and I would feel silly asking for any other features.

 

[CCTEX]

Good to hear. We need more members like you.


You play make believe very well.

It is quite a mess up there but I can give you another post if you would like. Post #3 is the download location now but I could bump it down to #4. if you would like.
As far a any other improvements I'm sure there are countless possibilities. Heck, you have already done so much and I would feel silly asking for any other features.

It is a mess up there. Maybe best would be if post 1 was for 1.7, 2 for 1.6, 3 for 1.5, and 4 for all archives. In posts 1-3 I will have the URL of the respective download links point to the archives attached to 4, removing existing archives from their posts. That should prevent any more issues with attachments I would think, and will give me the ability to clean it all up a bit. There are some interface changes in 1.7 as well as new features, so there will be new screenshots in its documentation.

As far as features, speak now or forever hold your peace, because 1.7's ready to go ! I'm sure there are countless possibilities, but if there is anything obviously useful that stands out in your mind, let me know.

 

[microdev]

[MENTION=6631]microdev[/MENTION] (or anyone else who cares to weigh in!), are you aware of any cases where there is more than 1 texture per row in a background or title?

Any skybox or backgrounds of Zelda Ocarina of Time, e.g. this one

 

[CCTEX]

Thanks [MENTION=6631]microdev[/MENTION]. Ive never worked with skyboxes, but I'm assuming you have to play the game and move your characters field of view around to get all the numbers, right? If thats the case, then the current screenshot method for roboread wouldn't work

 

[NES_player4LIFE]

...to play the game and move your characters field of view around to get all the numbers, right? If thats the case, then the current screenshot method for roboread wouldn't work

That's correct, Skybox would require 5 screenshots. The question then would be how to arrange them as there is no direction to define.
Whose to say what; Left, Up, Top, Right, and Down would be. These directions are user defined by direction of travel.

 

[CCTEX]

Ok good, because in 1.7, when using roboread, I disabled skybox as an option

 

[NES_player4LIFE]

Now let's think this through.
To dump all textures from this rom you will need to use RiceVideo 4.4.

If there is way to add support for multiple screenshots but remove redundant textures from being read and translated to the text output code it may work.

How about if a user could compile a panorama of sorts? Would this help?
User defined input. As they would know the angle to add, hopefully.

 

[CCTEX]

Now let's think this through. Here is A PD rom of Wii 64 (It's a skybox).
To dump all textures from this rom you will need to use RiceVideo 4.4 or if you would like I have included them.

If there is way to add support for multiple screenshots but remove redundant textures from being read and translated to the text output code it may work.

How about if a user could compile a panorama of sorts? Would this help?
User defined input. As they would know the angle to add, hopefully.

[MENTION=29958]NES_player4LIFE[/MENTION] Thanks for the files. I would love to add support for skyboxes but, for that to happen, I would need to write a brand new function from scratch as skyboxes are rendered in 3d space, not 2d, so there would be distortion in the angles of the textures in the screenshots... among several other factors. In short, it would be wildly more complicated, but not impossible! Maybe in v2.0 haha. Are you cool with my post above for the thread? If you can change it, I can release 1.7 and clean up the other top posts tonight.

 

[NES_player4LIFE]

I wouldn't say necessarily say 3D as the skybox is only a folded selection of textures (origami cube)
Thinking in the 4th dimension here. The Skybox is already supported we are just looking to find a shortcut.
That short cut could be found, maybe not before 2.0; but I have hope.

Are you cool with my post above for the thread? If you can change it, I can release 1.7 and clean up the other top posts tonight.

[MENTION=112808]CCTEX[/MENTION] Your project, your thread. Tell me if you need me to do anything for you.


Below is an idea for multi-shot compiling.

 

[CCTEX]

I wouldn't say necessarily say 3D as the skybox is only a folded selection of textures (origami cube)
Thinking in the 4th dimension here. The Skybox is already supported we are just looking to find a shortcut.
That short cut could be found, maybe not before 2.0; but I have hope.

[MENTION=112808]CCTEX[/MENTION] Your project, your thread. Tell me if you need me to do anything for you.


Below is an idea for multi-shot compiling.

Well yes, the textures are laid out in a 2d orientation, but when rendered by the virtual camera in an emulator, the z dimension is added for depth, causing distortion like the attached screenshot from the files you sent me for example

To the thread, I was referring to this post above, I will do all the clean up, I just need you to add a post on top, and change the name of the thread to 1.7.

It is a mess up there. Maybe best would be if post 1 was for 1.7, 2 for 1.6, 3 for 1.5, and 4 for all archives. In posts 1-3 I will have the URL of the respective download links point to the archives attached to 4, removing existing archives from their posts. That should prevent any more issues with attachments I would think, and will give me the ability to clean it all up a bit. There are some interface changes in 1.7 as well as new features, so there will be new screenshots in its documentation.