PDA

View Full Version : HighResEaser 1.7



CCTEX
September 15th, 2015, 03:29
HighResEaser 1.7 CCTEX MOD is here, more powerful, more user-friendly!

microdev's amazing HighResEaser (1.4 last official version (http://www.emutalk.net/threads/44436-HighResEaser-retexture-backgrounds-in-a-wink)) saves users a ton of time. My modifications of HRE on this thread serve to save you even more time with new features ranging from FULL automation of texture surveying/sorting to alternative methods of marking narrow textures when legibility is an issue.

Since MOD v1.6, the need to manually take note of the texture order has been eliminated; but the alternative marking methods I created remain in the script, and you can read the documentation of those features in MOD v1.5's release post in this thread. If you're new to HRE or retexturing, read the official documentation (http://www.emutalk.net/threads/44436-HighResEaser-retexture-backgrounds-in-a-wink) first.

Download HRE CCTEX MOD 1.7 (http://www.emutalk.net/attachment.php?attachmentid=39722&stc=1&d=1443385133)


New features
-ROBOREAD support for backgrounds/titles with multiple textures per row
-Detection/resolution of malformatted screenshots during ROBOREAD processing
-Realtime visual feedback during ROBOREAD processing
-User input error handling

Changes:
-Button/dropdown/help labels updated to be more intuitive
-ROBOREAD horizontal offset is a now relative percentage
-ALL resulting values are auto-filled & 'read only' after ROBOREAD

Bugfixes:
-Bugfix from original HRE that prevented loading transparent textures
-Bugfix from original HRE that crashed saving empty HiRes layer tiles
-Bugfix from HRE 1.6 that output ROBOWRITE colors at varying lengths


Watch the updated ROBOREADER demo from HRE 1.7


https://www.youtube.com/watch?v=lA4jZmVglyc&feature=youtu.be


Documentation of features introduced in this version:


Modification Utility 1: (Listed as 'ROBO-WRITE under the 'color/ROBO' drop-down in '1. Mark original textures| ROBOREAD/WRITE')
NOTE: This must be used prior to ROBO-READ.


Set scaling as desired, ID Position will be ignored. Select your source/save directories as usual. Your textures will be processed with encoded color overlays to be read later by ROBO-READ.

http://www.emutalk.net/attachment.php?attachmentid=39701&stc=1&d=1442823334



After encoding, you need to take a screenshot of the textures in use in the emulator. It should look like one of the examples below:

http://www.emutalk.net/attachment.php?attachmentid=39702&d=1442823967


If your textures do not fill entire screenshot (shown in the middle example above), you must crop the screenshot before processing with ROBOREAD


Modification Utility 2: (Listed as 'ROBO-READ under the 'color/ROBO' drop-down in '1. Mark original textures| ROBOREAD/WRITE')
NOTE: After processing your textures with ROBO-WRITE, you need to take a screenshot of the processed background textures while in use in the emulator.


All other parameters are ignored when using ROBO-READ.

http://www.emutalk.net/attachment.php?attachmentid=39703&d=1442824284



You will be asked for the directory containing your screenshot, make sure there are no other files in the directory other than your screenshot.

http://www.emutalk.net/attachment.php?attachmentid=39705&d=1442824892



You are then prompted for the total amount of textures (in total, not unique) contained in the screenshot. Be sure to enter this correctly:

http://www.emutalk.net/attachment.php?attachmentid=39708&d=1442825626



Now enter the amount of textures per row in the screenshot:

http://www.emutalk.net/attachment.php?attachmentid=39709&d=1442825632



Leave this as default (50%) if your screenshot contains multiple textures per row OR if your screenshot is unobscured by other textures like titles, popups, icons (which sometimes requires you to load blank transparents of those overlays into the emulator before taking your screenshot). Otherwise, if overlay obstacles obscure portions of your textures to be read, you can change the horizontal offset (%) from the left edge of each texture for its color sampling coordinate to provide a clear path to read the color bars all the way from top to bottom. In the screenshot example above, where the overlay 'MarioKart 64' took up the middle of the screen, a value of 5% or 95% would provide a clear path around the overlay.

http://www.emutalk.net/attachment.php?attachmentid=39710&d=1442825636



After a few seconds of processing the decoded values & TPR are automatically fed into Step 2 of HighResEaser! Simply press RUN, or copy the decoded values for future reference.

http://www.emutalk.net/attachment.php?attachmentid=39711&d=1442827043



If you did click RUN, you would continue just as in legacy HRE, selecting the directory containing the original textures, and watch them load up. Here is the result for the screenshot examples above:

http://www.emutalk.net/attachment.php?attachmentid=39712&d=1442827851


Thanks to microdev NES_player4LIFE mode7 Datadayne

CCTEX
September 15th, 2015, 05:24
This post is left for documentation of features introduced in v1.6

See first post for most current version and documentation of added features since this release

Download HighResEaser CCTEX MOD 1.6 (http://www.emutalk.net/attachment.php?attachmentid=39674&d=1442784194)


New features:
-ROBOWRITE function encodes textures to be automatically red by ROBOREAD
-ROBOREAD function decodes/arranges ROBOWRITE textures automatically

Changes:
-

Bugfixes:
-Bugfix from original HRE that prevented loading transparent textures


Watch the ROBOREADER demo from HRE 1.6:


https://www.youtube.com/watch?t=15&v=i_YX7EKRzDM



Documentation of features introduced in this version:


Modification Utility 1: (Listed as 'ROBO-WRITE under the 'font color' drop-down in 'Dialog 1 Load Mark Export...')
NOTE: This must be used prior to ROBO-READ.

Set scaling as desired, ID Position will be ignored. Select your source/save directories as usual. Your textures will be processed with encoded color overlays to be read later by ROBO-READ.

http://www.emutalk.net/attachment.php?attachmentid=39620&d=1442375798


You need to take a screenshot of the encoded textures in use in the emulator, it will look something like this:

http://www.emutalk.net/attachment.php?attachmentid=39700&d=1442817870



Modification Utility 2: (Listed as 'ROBO-READ under the 'ID position' drop-down in 'Dialog 1 Load Mark Export...')
NOTE: After processing your textures with ROBO-WRITE, you need to take a screenshot of the processed background textures while in use in the emulator.

All other parameters are ignored when using ROBO-READ.

http://www.emutalk.net/attachment.php?attachmentid=39621&d=1442375807


You will be asked for the directory containing your screenshot, make sure there are no other files in the directory other than your screenshot.
(Suggests creating New Folder @project64 (http://www.emutalk.net/member.php?u=48267)\Screenshot\New Folder)
Once directory is created simply move the Screenshot to the new folder.

http://www.emutalk.net/attachment.php?attachmentid=39622&d=1442376405


You are then prompted for the total amount of textures contained in the background. Be sure to enter this correctly:

http://www.emutalk.net/attachment.php?attachmentid=39624&d=1442377086


Before ROBO-READ processes the screenshot, you have a chance to change the horizontal offset (px) from its default of 1. ROBO-READ processes the screenshot in a straight line vertically from top to bottom. If there is any obstruction (such as a title texture, or other overlay) at the 1px mark, you can enter a horizontal offset value that will provide ROBO-READ a clear path to read the color bars all the way from top to bottom.

http://www.emutalk.net/attachment.php?attachmentid=39625&d=1442377269


After a few seconds of processing the decoded values are automatically fed into Step 2 of HighResEaser!

http://www.emutalk.net/attachment.php?attachmentid=39626&d=1442377776


From here you use the program as you normally would, clicking run, selecting the directory containing the original textures, and you're done. Here is the result for this example for the background textures:

http://www.emutalk.net/attachment.php?attachmentid=39627&d=1442377987


And there you have it. I hope it saves people time. Please note, I did not code input form error handling, so if you enter something goofy into the prompt boxes, you will get a goofy result :happy:

CCTEX
September 15th, 2015, 05:24
This post is left for documentation of features introduced in v1.5

See first post for most current version and documentation of added features since this release

Download HRE CCTEX MOD 1.5 (http://www.emutalk.net/attachment.php?attachmentid=39675&d=1442784708)


New features:
-HICONTRAST option marks textures with color coded circles, similar to an abacus
-NOBG option fills the textures with white for better legibility of the marks

Changes:
-

Bugfixes:
-


Documentation of features introduced in this version:



Modification Option 1: (Listed as 'NO BG' under the 'font color' drop-down in 'Dialog 1 Load Mark Export...')
Simply makes the background of the texture white for better legibility of marked textures in the emulator.

http://www.emutalk.net/attachment.php?attachmentid=39652&d=1442323892


Modification Option 2: (Listed as 'HICONTRAST' under the 'ID position' drop-down in 'Dialog 1 Load Mark Export...')

http://www.emutalk.net/attachment.php?attachmentid=39653&d=1442323902


Instead of numbers, colored circles are written to represent numbers, similar to an abacus, shown here:

http://www.emutalk.net/attachment.php?attachmentid=39662&d=1442722514


Un-modded shown here:

http://www.emutalk.net/attachment.php?attachmentid=39663&d=1442722584


As seen in the screenshots, the difference is night and day as far as legibility. In fact, I challenge anyone to read the numbers on the un-modded screenshot, I can't!

The numerical value for the circles are as follows:

Red: 1
Blue: 5
Green: 10

So if a line read GGGBRRR, that would be 38 (3 greens, 1 blue, 3 reds). Take a look at the screenshots if this is confusing. It is very simple when you see it visually.

CCTEX
September 15th, 2015, 23:12
Archives of every MOD since v1.5

NES_player4LIFE
September 15th, 2015, 23:44
This removes any human error, that is super cool.
You never cease to amaze!

@CCTEX (http://www.emutalk.net/member.php?u=112808)
Couldn't you have greater color range if you programmed a color sequence? You can go from 32 bit to 128 bit by having the script write and read color patterns instead of solid rows.

I'm not sure, but I don't think they exceed 10 or 14, 24 should be more then enough.
As far as the amount of textures per background; I don't think that they exceed 120.

CCTEX
September 16th, 2015, 00:36
@CCTEX (http://www.emutalk.net/member.php?u=112808)
Couldn't you have greater color range if you programmed a color sequence? You can go from 32 bit to 128 bit by having the script write and read color patterns instead of solid rows.

As far as the amount of textures per background; I don't think that they exceed 120.

I absolutely could do that. Right now, i just took the path of least resistance and used the existing variables that count the amount of 1s, 5s and 10s for the abacus, divide each corresponding RGB channel into sections corresponding to the maximum amount any of those variables could have (for example, 1s never exceed 4 so R is divided into 5 sections to represent 0-4), then assign a color value dead center of one of those sections that the script can later read from the screenshot you provide with a tolerance for the color being slightly off. I noticed PJ64 distorts color channels slightly so ranges were necessary. Definitely not the most logical way to do it, but it required the least amount of re-coding. If the amount of textures doesnt exceed 120, then i guess it doesnt matter anyway! Best part is, it takes under 3 seconds to process.

It might be useful to include an x axis offset option for when the script processes the color samples. Right now it statically samples 1,y all the way down. It may be useful if user could provide x in case there is an obstructing texture covering part of the background in the screenshot, you could have x correspond more towards the center or right side of the screen, depending on where the obstructing textures are located.

NES_player4LIFE
September 16th, 2015, 01:21
There must be a mathematical solution to separate alike colors from ever being next to each other within the same texture.
Shading colors are more likely to be misread I would think. A sequence of hard colors such as Red Yellow Blue Green would be safer.
I'm not sure what the code would be or how to find it.

As far as "obstructing textures" I have posted about this a few posts up. Not sure if it helps.

CCTEX
September 16th, 2015, 01:57
Considering i dont need to support more than 120 textures, theres no need to change anything as the existing code already handles the pj64 color degradation flawlessly. I just added the option for the user to choose the x coordinate for the sampling line. I put it in so users dont have to necessarily make transparent title/overlay textures to get a perfect, unobstructed screenshot, they can just leave them as is and tell the program where they want the sampling line to be, avoiding the obstructions.

Its actually ready to release, but I'm trying to see if theres a way to take that automated number/comma list and feed it directly into step 2 of his script, making it as seamless as possible, no having to restart the script, and no copying or pasting... Would be cool!

NES_player4LIFE
September 16th, 2015, 02:17
Sounds great, I was having a hard time trying to figure out how you would code RGB. 120 should be just right and if not this is still a huge improvement that can be refined.

One step processing would be even better. :)

CCTEX
September 17th, 2015, 10:15
Added support for up to 999 textures, CSV list is fed directly into step 2 of script, see version 1.6 above.

NES_player4LIFE
September 17th, 2015, 17:47
999 textures! This has me wondering if, with some tweaking; sprite mapping could become possible. It would require video capturing of game play and output to a 3d interactive spirit sheet. (Model of slices) (GIF).

CCTEX
September 18th, 2015, 06:39
1.6 Bugfix Update:

1. Found & fixed a bug of mine in the ROBOWRITE function when transparency is present in title textures, affecting the width of the encoded color overlays.

2. Found & fixed a similar bug of Microdev's present in his function for loading/arranging marked textures, which caused title textures with transparency to be cutoff.

The download link for version 1.6 has also been replaced in the master post to reflect these changes.

NES_player4LIFE
September 18th, 2015, 15:58
1.6 Bugfix Update:

1. Found & fixed a bug of mine in the ROBOWRITE function when transparency is present in title textures, affecting the width of the encoded color overlays.

2. Found & fixed a similar bug of Microdev's present in his function for loading/arranging marked textures, which caused title textures with transparency to be cutoff.

The download link for version 1.6 has also been replaced in the master post to reflect these changes.

That's right! I had forgotten that HRE shrinks the image to only use the visible texture thus causing a read error.
Thanks for the fix!
CCTEX I have yielded my first post in this thread to you, thus granting you a third top post to add attachments.
Please keep attachments with in the top posts for the sake of organization. This way information is not buried deep in the thread.

microdev
September 18th, 2015, 16:00
2. Found & fixed a similar bug of Microdev's present in his function for loading/arranging marked textures, which caused title textures with transparency to be cutoff.

Great to finally see someone giving some love to this tool. Especially this bug is something I wanted to fix for a ages but never did...

However I was under the impression that this is a bug with the photoshop scripting engine. Thus I wanted to fix it by setting an intransparent dot to the upper left and lower right corner and replacing it with the right pixel after the tile has been placed. But as you mentioned it seems to be a bug in the script. Just out of curiosity - could you please show me what you fixed?

I have not objections at all to whatever is done with this tool as long as the license is respected (GPL v2)

CCTEX
September 18th, 2015, 21:05
Great to finally see someone giving some love to this tool. Especially this bug is something I wanted to fix for a ages but never did...

However I was under the impression that this is a bug with the photoshop scripting engine. Thus I wanted to fix it by setting an intransparent dot to the upper left and lower right corner and replacing it with the right pixel after the tile has been placed. But as you mentioned it seems to be a bug in the script. Just out of curiosity - could you please show me what you fixed?

I have not objections at all to whatever is done with this tool as long as the license is respected (GPL v2)

Hey microdev!

I only changed one variable in one line of your code for the fix:



//CCBUGFIX
newDoc.resizeCanvas((rowCount*texture.wi dth),(Math.ceil(displayOrder.length/rowCount))*tileHeight)
//newDoc.resizeCanvas((rowCount*tileWidth) ,(Math.ceil(displayOrder.length/rowCount))*tileHeight)
//CCBUGFIX


I made a similar "mistake" in one of my add-ons, that's why I noticed it. It's really not an issue with the scripting engine, it's how photoshop behaves when in normal use as well.

For example:

You have a transparent document 400x400 px with a 10x10 px solid red square dead center, you select all, copy, new document, and when that new document dialog appears, the suggested size will be 10x10 not 400x400, because empty space isn't copied to clipboard.

Cheers, glad you approve

CCTEX
September 19th, 2015, 00:12
That's right! I had forgotten that HRE shrinks the image to only use the visible texture thus causing a read error.
Thanks for the fix!
CCTEX I have yielded my first post in this thread to you, thus granting you a third top post to add attachments.
Please keep attachments with in the top posts for the sake of organization. This way information is not buried deep in the thread.

Will do, I wasn't able to re-add the attachment to the second post last night for some reason, that's why it was in the post above. Speaking to organization, is there any way to swap the order of post 1 and 2? Seems like it would make more sense.

NES_player4LIFE
September 19th, 2015, 01:02
I'll see what I can do.
As it turns out there is a 10 attachment limit per post.

CCTEX
September 19th, 2015, 21:23
microdev (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? NES_player4LIFE and I are not, but if you have an example, can you tell me which game so I can test? I need to further modify the original code to fix distortion with loading textures with transparency, AND, (I forgot before) do the same thing for your exporting function of the high res slices. Thanks!

NES_player4LIFE
September 19th, 2015, 23:48
@CCTEX (http://www.emutalk.net/member.php?u=112808). Yes there in fact screens that contain a range of textures. An example would be Space Invaders.
These textures are offset by 76 pixels in the center. The area in question belongs to the left hand most side of the screen and are displaced to the center column.

EDIT PSD added

CCTEX
September 19th, 2015, 23:59
Ok, currently, ROBO READ does not support multiple textures per row, shall I add support then? If so, could you possibly post the invaders textures you're talking about so I can test the new code?
FYI, I've now completely fixed the bug from original HRE in a somewhat unorthodox way.

Update: NES_player4LIFE whoops, didn't see your attachment

NES_player4LIFE
September 20th, 2015, 00:12
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
September 20th, 2015, 00:33
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,ColorBl endMode.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,ColorBl endMode.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:

http://www.emutalk.net/attachment.php?attachmentid=39660&d=1442705423
vs
http://www.emutalk.net/attachment.php?attachmentid=39661&d=1442705428

NES_player4LIFE
September 20th, 2015, 00:39
Hard file/Textures. Anyhow they are now located in the Space Invaders issue post (http://www.emutalk.net/threads/55757-HighResEaser-1-6?p=457327&viewfull=1#post457327).
Oh, that, thanks man!

CCTEX
September 20th, 2015, 05:31
Hard file/Textures. Anyhow they are now located in the Space Invaders issue post (http://www.emutalk.net/threads/55757-HighResEaser-1-6?p=457327&viewfull=1#post457327).
Oh, that, thanks man!

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

NES_player4LIFE
September 20th, 2015, 17:58
Thanks!

Where you able to migrate those 76PX?

CCTEX
September 20th, 2015, 21:03
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
September 20th, 2015, 22:04
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
September 20th, 2015, 22:22
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
September 20th, 2015, 22:30
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. :D

Tell me where did you learn to code?

CCTEX
September 20th, 2015, 22:37
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
September 20th, 2015, 22:47
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
September 20th, 2015, 23:19
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 [emoji1] ! I'm sure there are countless possibilities, but if there is anything obviously useful that stands out in your mind, let me know.

microdev
September 20th, 2015, 23:33
microdev (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 (http://www.emutalk.net/threads/44436-HighResEaser-retexture-backgrounds-in-a-wink?p=447443&viewfull=1#post447443)

CCTEX
September 21st, 2015, 00:24
Thanks microdev. 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
September 21st, 2015, 00:54
...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
September 21st, 2015, 01:08
Ok good, because in 1.7, when using roboread, I disabled skybox as an option

NES_player4LIFE
September 21st, 2015, 01:36
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
September 21st, 2015, 02:08
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.
NES_player4LIFE 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
September 21st, 2015, 02:24
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. CCTEX Your project, your thread. Tell me if you need me to do anything for you.
:)

Below is an idea for multi-shot compiling.

CCTEX
September 21st, 2015, 02:46
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.

CCTEX 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.

NES_player4LIFE
September 21st, 2015, 03:15
We'll put that on the back burner then. :satisfied

CCTEX
September 21st, 2015, 10:59
We'll put that on the back burner then. :satisfied

Despite my reservations, I'd love to figure out a way to do it though.

Otherwise, version 1.7 has been released, it's awesome, and can be found here (http://www.emutalk.net/threads/55757-HighResEaser-1-7). I don't know what was more complicated, coding this script or organizing the top posts of this thread! :devil:

NES_player4LIFE
September 21st, 2015, 16:04
"Drum beat"

Probably organizing the posts. I had to copy that post from one of your earlier topics to be able to inject it into the top spot as posts are placed in chronological order.

If you can't get to it, so be it, you have already done so much.

CCTEX
September 21st, 2015, 23:16
"Drum beat"

Probably organizing the posts. I had to copy that post from one of your earlier topics to be able to inject it into the top spot as posts are placed in chronological order.

If you can't get to it, so be it, you have already done so much.
Well at least it all makes sense up there now!

Let me know what you think of 1.7 when you try it out.

NES_player4LIFE
September 21st, 2015, 23:40
ROBO read issue:
Script asks for the amount of textures to be read but won't except the input. I need ten textures per row.

CCTEX
September 22nd, 2015, 00:05
ROBO read issue:
Script asks for the amount of textures to be read but won't except the input. I need ten textures per row.
That's odd, it accepts all numbers from 1-999, but I specifically tested it with 10 in particular numerous times. Stupid question, but you are typing 10 not ten, right? Also no punctuation.

Post a screenshot possibly

UPDATE: Just tested with the 1.7 archive uploaded to emutalk, no issues experienced

NES_player4LIFE
September 22nd, 2015, 02:09
I tried 10 1.0 and ten. I've also typed random values. Nothing it asks me to enter a value between 1-999.
http://i60.tinypic.com/308jzx5.png

CCTEX
September 22nd, 2015, 02:12
I tried 10 1.0 and ten. I've also typed random values. Nothing it asks me to enter a value between 1-999.
http://i60.tinypic.com/308jzx5.png
What version of photoshop?

NES_player4LIFE
September 22nd, 2015, 02:17
I've tried both CS5 12.1(64bit) and CS3 10.0

CCTEX
September 22nd, 2015, 02:19
I've tried both CS5 12.1(64bit) and CS3 10.0
That's so odd, I can't recreate the issue... this shouldn't matter, but post your screenshot. That's the only other variable I can think of

NES_player4LIFE
September 22nd, 2015, 02:21
There is no difference between versions. Warning are the same.

CCTEX
September 22nd, 2015, 02:22
There is no difference between versions. Warning are the same.
Lol, no I mean your texture screenshot :)

NES_player4LIFE
September 22nd, 2015, 02:31
Issue present in both single file per row entry and multi file per row.

Mariokart64 codes correctly with 1.6 but not 1.7.
Thinking it's a PS issue.

CCTEX
September 22nd, 2015, 02:44
Issue present in both single file per row entry and multi file per row.

Mariokart64 codes correctly with 1.6 but not 1.7.
Thinking it's a PS issue.
Hmmm... try deleting line #814 from the code

NES_player4LIFE
September 22nd, 2015, 02:49
Asks for percentage... Asks for a value 0-100 50% is def. Returns to ask for percentage.

CCTEX
September 22nd, 2015, 02:53
Ok, so that means your photoshop scripting engine doesn't like the error handling altogether. Delete line 825 (or 824 depending on how you deleted 814). The line starts with "if (xoffset..."

NES_player4LIFE
September 22nd, 2015, 02:58
Successfully decoded texture sequence from 120 values!

#814
#825
Backspaced by highlighting and hitting (Del) key

CCTEX
September 22nd, 2015, 03:05
Successfully decoded texture sequence from 120 values!

#814
#825
Backspaced by highlighting and hitting (Del) key
Awesome! I should mention that the tiled screenshot you're using will need to have the top and bottom rows (the ones with only two textures) cropped out before processing. Roboread only supports same amount of textures per row.

NES_player4LIFE
September 22nd, 2015, 03:11
Trips at arrange.

As code is in error.


68,101,27,53,35,28,30,115,3,81,13,14,64, 55,
49,17,12,6,116,69,0,0,0,555,555,555,
444,444,444,444,444,0,0,0,0,444,444,444, 444,0,
25,18,33,19,98,102,9,9,9,9,9,9,3,3,3,73, 20,45,
38,82,41,120,31,99,42,4,105,96,104,106,3 6,34,107,95,52,10,23,67,29,43,113,7,37,
71,39,47,58,16,74,109,410,970,950,940,93 0,900,22,
83,72,94,15,111,444,444,444,333,0,9,112, 87,70,40,110,65,114,24,46,8,88,54

Note the repeating values.

CCTEX
September 22nd, 2015, 03:14
Can you post the files, including your screenshot? I'd like to see if it's a problem with your photoshop.

NES_player4LIFE
September 22nd, 2015, 03:15
Awesome! I should mention that the tiled screenshot you're using will need to have the top and bottom rows (the ones with only two textures) cropped out before processing. Roboread only supports same amount of textures per row.
Errr? You're talking about the range mode correct?


Can you post the files, including your screenshot? I'd like to see if it's a problem with your photoshop.
I think I know what I did to cause the misread error. That SC was for use with 1.6.

Starting from scratch.

CCTEX
September 22nd, 2015, 03:20
Not sure what you mean by range mode. Im talking about the screenshot where the top and bottom rows have two textures, and every other row has 10 textures. You need to crop out the top and bottom rows, because they differ.

NES_player4LIFE
September 22nd, 2015, 03:23
http://wp.production.patheos.com/blogs/naturalwonderers/files/2013/04/kitten-hang-in-there-poster.jpg

CCTEX
September 22nd, 2015, 03:30
Not sure what you mean by range mode. Im talking about the screenshot where the top and bottom rows have two textures, and every other row has 10 textures. You need to crop out the top and bottom rows, because they differ.
I just realized I may be making a false assumption about the top and bottom rows. Take the top row for example, I'm assuming that it is made up of two long textures. Is it actually 1 texture repeated 5 times, then another texture repeated 5 times, like in the Activision logo? If that's the case then all you need to do is crop the empty black space surrounding the screenshot, as you always have to do.

NES_player4LIFE
September 22nd, 2015, 03:49
Range mode is when a SC contains Rows and Columns. A range of textures.
The top textures are in fact the same file repeated.

My issue is that 1.7 fails to operate correctly and enters false values into Step #2 Load and Arrange.


68,101,27,53,35,28,30,115,3,81,13,14,64, 55,49,17,0,0,0,666,666,0,0,
666,666,666,666,666,0,0,0,0,0,777,777,77 7,777,0,0,66,25,18,33,19,98,102,9,9,9,9, 9,9,3,3,3,73,20,45,38,82,41,120,
31,99,42,4,105,96,104,106,36,34,107,95,5 2,10,23,67,29,43,113,7,37,71,39,47,58,16 ,74,109,
410,970,950,940,930,900,22,83,72,94,15,1 11,444,444,444,333,0,9,112,87,70,40,110, 65,114,24,46,0,111,0

These are from MK64 (120) textures.

CCTEX
September 22nd, 2015, 03:59
Range mode is when a SC contains Rows and Columns. A range of textures.
The top textures are in fact the same file repeated.

My issue is that 1.7 fails to operate correctly and enters false values into Load and Arrange.


68,101,27,53,35,28,30,115,3,81,13,14,64, 55,49,17,0,0,0,666,666,0,0,
666,666,666,666,666,0,0,0,0,0,777,777,77 7,777,0,0,66,25,18,33,19,98,102,9,9,9,9, 9,9,3,3,3,73,20,45,38,82,41,120,
31,99,42,4,105,96,104,106,36,34,107,95,5 2,10,23,67,29,43,113,7,37,71,39,47,58,16 ,74,109,
410,970,950,940,930,900,22,83,72,94,15,1 11,444,444,444,333,0,9,112,87,70,40,110, 65,114,24,46,0,111,0

These are from MK64 (120) textures.
NES_player4LIFE
The problem is you are leaving the horizontal offset at the default 50% (This default changed from 1.6), so it is sampling straight down the center of the screenshot where it picks up invalid values from the 'MARIOKART 64' title text. If you entered 95%, it would take its samples near the right edge of the screen capture, avoiding that obstruction. In 1.7, you can actually see the dropper tool getting its samples while its processing, so you can see where its getting samples in real time. (at least you can in CS6)

NES_player4LIFE
September 22nd, 2015, 04:12
Ah, 95% That's corrected now! MK64 seems to process correctly

I now have an issue with the Range in Space Invaders. I input the SC and it processes but after it reads the SC it fails to direct to step 2.

CCTEX
September 22nd, 2015, 04:14
Ah, 95% That's corrected now! MK64 seems to process correctly

I now have an issue with the Range in Space Invaders. I input the SC and it processes but after it reads the SC it fails to direct to step 2.
Did you make sure to crop out the black space surrounding the textures in your screenshot? Also, leave offset at 50%

NES_player4LIFE
September 22nd, 2015, 04:33
I seemed to have missed that command, Cropped and seems to be working now. Sorry for the run-a-round.
Tested on PS CS5 not yet CS3.

CCTEX
September 22nd, 2015, 04:50
NES_player4LIFE No worries!

Instead of deleting the lines I told you, try loading up the official 1.7 and replace the following lines with these lines. If it works for you, then that means older versions of photoshop don't handle 'regular expressions' for some bizarre reason.

803:
if ( slicesint > 0 && slicesint < 1000 )
814:
if ( tprint > 0 && tprint < 1000 )
825:
if ( xoffsetflt >= 0 && xoffsetflt <= 100 )

NES_player4LIFE
September 22nd, 2015, 19:00
@NES_player4LIFE (http://www.emutalk.net/member.php?u=29958) No worries!

Instead of deleting the lines I told you, try loading up the official 1.7 and replace the following lines with these lines. If it works for you, then that means older versions of photoshop don't handle 'regular expressions' for some bizarre reason.

803:
if ( slicesint > 0 && slicesint < 1000 )
814:
if ( tprint > 0 && tprint < 1000 )
825:
if ( xoffsetflt >= 0 && xoffsetflt <= 100 )

So far so good.

CCTEX
September 22nd, 2015, 21:03
So far so good.

Ok good. I'm actually glad there was confusion, becuase it gave me the idea to add the feature shown in the screenshot below. I figured out a very reliable way of detecting when the user has made a mistake, and it pops up a dialog offering solutions, before it starts to try arranging textures with your corrupt numbers)

http://www.emutalk.net/attachment.php?attachmentid=39716&stc=1&d=1442951462

So the hope is, that if this feature was there before, it would catch the errors before they become bewildering. I attached the modified 1.7, if it works on your machine, I'll replace the main archive!

(It already has the changes to the input error handling from two posts ago without 'regular expressions'.)

NES_player4LIFE
September 22nd, 2015, 21:55
That works great. I would as for a report of what files where interrupted and the amount of such errors ignored or a correction input.
Say that you have scanned 90% of the SC but the last 10% contains external graphics, could a user then ask to scan a separate portion of the file in error?

CCTEX
September 23rd, 2015, 02:40
That works great. I would as for a report of what files where interrupted and the amount of such errors ignored or a correction input.
Say that you have scanned 90% of the SC but the last 10% contains external graphics, could a user then ask to scan a separate portion of the file in error?

Good to hear it works. I programmed the addition in basic javascript, with no regular expressions, to make sure it worked in older photoshop versions (pain in the ass lol).

To your first question, ROBOREADER only sees the screenshot you provide, it does not load any files or metadata. The way it is able to detect various mistakes is by intelligently tallying up the amount of unique color samples (which should equal the amount of texture files), finding the largest decoded sample VALUE, and then making sure that largest decoded sample value isn't greater than the amount of unique samples tallied. It also makes sure that no sample value is less than 1.

Since ROBOWRITE encodes the textures sequentially, starting from 1, this detection method will throw an error when it encounters pure black, or any decoded color value out of the range of the total unique values it finds.

To attempt to provide specific information to the user would be more misleading than helpful, because for one, the error detection is based off of the prompt values inputted by the user which could easily be incorrect anyway. The logic would end up being circular.

Question 2: Can you elaborate, or provide an example screenshot?

(Update:) NES_player4LIFE I just tried to respond to your PM, says your inbox quota is exceeded.

- - - Updated - - -


Good to hear it works. I programmed the addition in basic javascript, with no regular expressions, to make sure it worked in older photoshop versions (pain in the ass lol).

To your first question, ROBOREADER only sees the screenshot you provide, it does not load any files or metadata. The way it is able to detect various mistakes is by intelligently tallying up the amount of unique color samples (which should equal the amount of texture files), finding the largest decoded sample VALUE, and then making sure that largest decoded sample value isn't greater than the amount of unique samples tallied. It also makes sure that no sample value is less than 1.

Since ROBOWRITE encodes the textures sequentially, starting from 1, this detection method will throw an error when it encounters pure black, or any decoded color value out of the range of the total unique values it finds.

To attempt to provide specific information to the user would be more misleading than helpful, because for one, the error detection is based off of the prompt values inputted by the user which could easily be incorrect anyway. The logic would end up being circular.

In line with my comment above, I think this is a good compromise. If the user chooses to proceed, ignoring the first error encountered, a secondary dialog appears at the end, listing how many errors were found, and where they are in the screenshot. It doesn't draw the conclusion for the user (as it cant), but it provides more information to assist in tracking down what he/she is doing wrong.

http://www.emutalk.net/attachment.php?attachmentid=39719&d=1442972203

An updated version of the test script reflecting this change is attached.

NES_player4LIFE
September 24th, 2015, 01:30
In line with my comment above, I think this is a good compromise. If the user chooses to proceed, ignoring the first error encountered, a secondary dialog appears at the end, listing how many errors were found, and where they are in the screenshot. It doesn't draw the conclusion for the user (as it cant), but it provides more information to assist in tracking down what he/she is doing wrong.
This sound exactly like what I wanted, I do doubt that it will be used much but in such cases it will help to track errors.

I'll see about testing the latest script this weekend.

EDIT: Inbox cleaned up thanks.

NES_player4LIFE
September 27th, 2015, 14:13
CCTEX I've tested the script and all seems to be well on this end. I think it's time to wrap up this project and move on to the next one. :D

CCTEX
September 27th, 2015, 21:25
CCTEX I've tested the script and all seems to be well on this end. I think it's time to wrap up this project and move on to the next one. :D

Cool, I just replaced the archive and the link in the top post. FYI, the link to this thread from md's original thread is dead.

NES_player4LIFE
September 28th, 2015, 01:58
FYI, the link to this thread from md's original thread is dead.
That may be to all the activity; thanks for telling me I'll fix it now.

death--droid
November 8th, 2015, 04:50
Oooh this looks rather neat, and should save an awful lot of time when doing some of those pesky backgrounds!!

NES_player4LIFE
November 8th, 2015, 13:36
A user can now pack a days worth of work into about 2 Min's. (30 sec if you know what you are doing)

NES_player4LIFE
August 9th, 2017, 22:13
CCTEX microdev
Added some tips to the prompts.

CCTEX
August 10th, 2017, 05:02
CCTEX microdev
Added some tips to the prompts.

Cool, I'll check it out... Blast from the past haha!

NES_player4LIFE
August 10th, 2017, 22:40
It's nothing major. I only edited a few lines.

Cctex it's been a while, nice to see you around.

EmuNoviceUser
June 4th, 2018, 17:59
I have a question (cannot run the script at the moment due to an error, but I felt I should ask anyway):

As I understand it, you dump the necessary .png files, take a screenshot of the same area, and the script pieces the textures together into a single image using the screenshot as a guide. (If I am wrong, let me know, of course), but how does this work if there are other objects blocking the background that you cannot get out of the way?

Mollymutt
June 4th, 2018, 21:26
No. Basically, you open the script in photoshop, and have it number all of the textures from a folder. Then you go into the emu, and you can see how the textures fit together. Then you have to put them together in one big file in photoshop, edit the picture, then let highreseaser split them back up for you. Since there's a little overlap in the texturers ingame, it makes this part much easier.

EmuNoviceUser
June 5th, 2018, 16:31
Oh, alright. That makes a LOT more sense. I think that I can write my own script to do something a bit more basic but similar since I cannot get this one to work... but at least I will fully understand and be able to control mine.

Thanks.