• ✨ ARCHIVE MODE ✨
    The forum has now been set to read-only mode, no new posts, resources, replies etc will not be possible.
    We recommend you join our Discord server to get real-time response: Discord Invite Link

Trainer Sprites

Status
Not open for further replies.

DracoHouston

Kolben Developer
Contributor
<< Needless to say, Hilbert looks absolutely fabulous on high heels.

I also think Oak's body simply requires a big head to fit with it.

This was a quick swapping really. Fitting both parts is on photoshop really simple copy/paste work, and each head fits in differently with another's body. I don't know if it's as easy using "a simple program" to shift the head 2 pixels up if Oak's body is used, or 2 pixels down if nurse Joy's body is used.
this is where attachments could come in, in fps games they define a point as a socket or attachment (usually just an origin and maybe direction) so things know where to go (like putting a gun in a character's hand, putting your character on top of your mount in WoW and so on). Body skins could come with a matching .dat file that says where the head goes. or you could use a pixel coloured a certain colour (say, 255 red, 0 green, 255 blue, really bright pink, if someone wanted to use pink they'd just have to not use exactly 255 red and 255 blue, 255 red and 254 blue wouldnt be picked up for example) and the game sticks the head to that spot. you could also maybe just get the height by seeing where the sprite stops in the image (checking for a transparent area that could reasonably be the wasted space above the sprite).

i think making the attachment point something you can set per frame would work the best. look at the difference in posture here


(by the way, the xnbs for those are in the same folder on that server)
 

DracoHouston

Kolben Developer
Contributor
We need Kris.
you have everything you need right there to make one yourself. the tools and instructions for compiling textures into xnb's are in the first link in my sig. You can change your skin by opening your save game's Player.dat and change 'skin' to the file name of the xnb you made. I'm playing as falkner lately :)
 

DracoHouston

Kolben Developer
Contributor
you have everything you need right there to make one yourself.
Yeah... I tried editing textures but the game crashes every time it tries to load one of my xnbs.
they have to be outputted to the right folder, so put xnaformatter in your pokemon folder and use /Pokemon/Content/Textures/NPC/ as the output folder. for tile sets it is /Pokemon/Content/Textures.

Compile for windows game with reach profile and compression. don't check the other 2 boxes
 

Tav

Fisherman
<< Needless to say, Hilbert looks absolutely fabulous on high heels.

I also think Oak's body simply requires a big head to fit with it.

This was a quick swapping really. Fitting both parts is on photoshop really simple copy/paste work, and each head fits in differently with another's body. I don't know if it's as easy using "a simple program" to shift the head 2 pixels up if Oak's body is used, or 2 pixels down if nurse Joy's body is used.
this is where attachments could come in, in fps games they define a point as a socket or attachment (usually just an origin and maybe direction) so things know where to go (like putting a gun in a character's hand, putting your character on top of your mount in WoW and so on). Body skins could come with a matching .dat file that says where the head goes. or you could use a pixel coloured a certain colour (say, 255 red, 0 green, 255 blue, really bright pink, if someone wanted to use pink they'd just have to not use exactly 255 red and 255 blue, 255 red and 254 blue wouldnt be picked up for example) and the game sticks the head to that spot. you could also maybe just get the height by seeing where the sprite stops in the image (checking for a transparent area that could reasonably be the wasted space above the sprite).

i think making the attachment point something you can set per frame would work the best. look at the difference in posture here


(by the way, the xnbs for those are in the same folder on that server)
Aha. That actually makes sense. :) Then this will be a fun thing to do in my vacation...

I'm going to attempt to replace the current tilesets with actual HG/SS tilesets partially. Only partially because the real poke center/marts are 3d and quite simply undoable without the necessary map-editing knowledge from your thread. Let's see how far I'll get with that. :dead: (starting in cherrygrove city tileset, seems to be easiest?)
 

DracoHouston

Kolben Developer
Contributor
Aha. That actually makes sense. :) Then this will be a fun thing to do in my vacation...

I'm going to attempt to replace the current tilesets with actual HG/SS tilesets partially. Only partially because the real poke center/marts are 3d and quite simply undoable without the necessary map-editing knowledge from your thread. Let's see how far I'll get with that. :dead: (starting in cherrygrove city tileset, seems to be easiest?)
Hmmm, I was contemplating that but it seems like with the areas using g/s tiles mostly it'd be easier just to stick with those. It is well within your power right now to do a pokemon3d:hd patch, if you were willing.

All retexturing that changes the texture resolution will require changes to maps, this is because tile sets are done as a texture atlas, its multiple tiles in a single image. this is woodtower, the tile set i made for sprout tower, its an old version though, nilllzz ended up using the map and changed some of it to make it look nicer

so lets look at the floor in sprout tower floor 1
Code:
Floor:
right:
{"Floor"{ENT[{"Size"{intArr[8,18]}}{"Position"{intArr[-1,0,-1]}}{"TexturePath"{str[WoodTower]}}{"Texture"{rec[0,0,16,16]}}]}}
left:
{"Floor"{ENT[{"Size"{intArr[8,18]}}{"Position"{intArr[9,0,-1]}}{"TexturePath"{str[WoodTower]}}{"Texture"{rec[0,0,16,16]}}]}}
middle:
{"Floor"{ENT[{"Size"{intArr[2,6]}}{"Position"{intArr[7,0,9]}}{"TexturePath"{str[WoodTower]}}{"Texture"{rec[0,0,16,16]}}]}}
{"Floor"{ENT[{"Size"{intArr[2,8]}}{"Position"{intArr[7,0,-1]}}{"TexturePath"{str[WoodTower]}}{"Texture"{rec[0,0,16,16]}}]}}
mat:
{"Floor"{ENT[{"Size"{intArr[1,1]}}{"Position"{intArr[7,0,15]}}{"TexturePath"{str[WoodTower]}}{"Texture"{rec[16,32,16,16]}}]}}
{"Floor"{ENT[{"Size"{intArr[1,1]}}{"Position"{intArr[8,0,15]}}{"TexturePath"{str[WoodTower]}}{"Texture"{rec[32,32,16,16]}}]}}
strip after mat:
{"Floor"{ENT[{"Size"{intArr[2,2]}}{"Position"{intArr[7,0,16]}}{"TexturePath"{str[WoodTower]}}{"Texture"{rec[0,0,16,16]}}]}}
The parts you need to edit are TexturePath and Texture. TexturePath is the name of the xnb from the textures folder you are using. if you have it in a new folder inside textures you need to specify folder, so say your stuff was in Textures/HD you would set it to
{"TexturePath"{str[HD\WoodTower]}}
but you could just name your tile sets like WoodTowerGen4 or HD or HGSS or w/e you wanted. I would advise against making your stuff actually overwrite the official maps. You can easily copy the maps and textures and edit those copies, there is room for both that way.

the other subtag is texture, it takes 4 arguments, the first 2 say where to start from in the image. For the floor texture that is 0,0, the top left corner of the set. the mat is made of 2 floor blocks with different textures applied, 16,32 and 32,32, check where they are in my set. basically, you need to tell it the pixel the top left corner of your tile is in the image.

The other 2 arguments are the tile size. this is how big your tile is, in pixels. all of mine are 16x16. if you are going to use hg/ss ones they will be much larger. this is why replacing the textures with bigger ones won't work straight away. You can just copy the map files and edit all the texturepaths and texture subtags to suit, you wouldn't have to remake the map itself. certain things changed about layout in hg/ss that'd need some mapping to do, but for the most part you can use copies of the official maps to do it.
 

Tav

Fisherman
Hmmm, I was contemplating that but it seems like with the areas using g/s tiles mostly it'd be easier just to stick with those. It is well within your power right now to do a pokemon3d:hd patch, if you were willing.

All retexturing that changes the texture resolution will require changes to maps, this is because tile sets are done as a texture atlas, its multiple tiles in a single image. this is woodtower, the tile set i made for sprout tower, its an old version though, nilllzz ended up using the map and changed some of it to make it look nicer

so lets look at the floor in sprout tower floor 1
Code:
Floor:
right:
{"Floor"{ENT[{"Size"{intArr[8,18]}}{"Position"{intArr[-1,0,-1]}}{"TexturePath"{str[WoodTower]}}{"Texture"{rec[0,0,16,16]}}]}}
left:
{"Floor"{ENT[{"Size"{intArr[8,18]}}{"Position"{intArr[9,0,-1]}}{"TexturePath"{str[WoodTower]}}{"Texture"{rec[0,0,16,16]}}]}}
middle:
{"Floor"{ENT[{"Size"{intArr[2,6]}}{"Position"{intArr[7,0,9]}}{"TexturePath"{str[WoodTower]}}{"Texture"{rec[0,0,16,16]}}]}}
{"Floor"{ENT[{"Size"{intArr[2,8]}}{"Position"{intArr[7,0,-1]}}{"TexturePath"{str[WoodTower]}}{"Texture"{rec[0,0,16,16]}}]}}
mat:
{"Floor"{ENT[{"Size"{intArr[1,1]}}{"Position"{intArr[7,0,15]}}{"TexturePath"{str[WoodTower]}}{"Texture"{rec[16,32,16,16]}}]}}
{"Floor"{ENT[{"Size"{intArr[1,1]}}{"Position"{intArr[8,0,15]}}{"TexturePath"{str[WoodTower]}}{"Texture"{rec[32,32,16,16]}}]}}
strip after mat:
{"Floor"{ENT[{"Size"{intArr[2,2]}}{"Position"{intArr[7,0,16]}}{"TexturePath"{str[WoodTower]}}{"Texture"{rec[0,0,16,16]}}]}}
The parts you need to edit are TexturePath and Texture. TexturePath is the name of the xnb from the textures folder you are using. if you have it in a new folder inside textures you need to specify folder, so say your stuff was in Textures/HD you would set it to
{"TexturePath"{str[HD\WoodTower]}}
but you could just name your tile sets like WoodTowerGen4 or HD or HGSS or w/e you wanted. I would advise against making your stuff actually overwrite the official maps. You can easily copy the maps and textures and edit those copies, there is room for both that way.

the other subtag is texture, it takes 4 arguments, the first 2 say where to start from in the image. For the floor texture that is 0,0, the top left corner of the set. the mat is made of 2 floor blocks with different textures applied, 16,32 and 32,32, check where they are in my set. basically, you need to tell it the pixel the top left corner of your tile is in the image.

The other 2 arguments are the tile size. this is how big your tile is, in pixels. all of mine are 16x16. if you are going to use hg/ss ones they will be much larger. this is why replacing the textures with bigger ones won't work straight away. You can just copy the map files and edit all the texturepaths and texture subtags to suit, you wouldn't have to remake the map itself. certain things changed about layout in hg/ss that'd need some mapping to do, but for the most part you can use copies of the official maps to do it.
Yes, correct. I simply decided to start within the 16x16 pixel to see what it all looks like, and see what needs fixes. I'll admit that so far, the retexturing looks like sh*t but hey, not bad for a first attempt :p Added screenies, You'll see that the roof textures suck. But I blame the fact that I had to make them myself since the original HG/SS didn't have any for me.

The pokemart/center signs are kind of unnecessary considering the huge poles are there to show what they are.

The last screenshot with the rocks on the water, I'll need to modify them so they "stand" on the water and not lay there. I assume that I'll need to modify them so they have a front image and a side image just like the signs have, and I'll have to refer to the flowers as an example for the coding?

A bird-view mode would be appreciated for retexturing. *hint hint* :rolleyes:

(I also seem to be going rather far off-topic now, if a mod feels it is more appropriate in the mapping thread, feel free to move this post. Sorry!)
 

Attachments

MrTimoshi

Fisherman
Nilllzz said on the original forum that we could make higher resolution textures as long as we increase the pixel size in the map and recalculate the map positions. I'm not sure what values in the code control that because he never got back to me... but it should work according to him.
 

BakaOnibi

Trainer
Donator
Nilllzz said on the original forum that we could make higher resolution textures as long as we increase the pixel size in the map and recalculate the map positions. I'm not sure what values in the code control that because he never got back to me... but it should work according to him.
This part is used for the textures:

Code:
{"Texture"{rec[0,0,16,16]}}
The first two numbers are the co-ordinates for the starting point/first pixel, the next two define the size. So for example if the texture I wanted was 32x32, not 16x16, I would change the code to:
Code:
{"Texture"{rec[0,0,32,32]}}
You shouldn't need to change the position or size as your texture should be scaled to a single block in the game. You just need to change the texture.
 
this is where attachments could come in, in fps games they define a point as a socket or attachment (usually just an origin and maybe direction) so things know where to go (like putting a gun in a character's hand, putting your character on top of your mount in WoW and so on). Body skins could come with a matching .dat file that says where the head goes. or you could use a pixel coloured a certain colour (say, 255 red, 0 green, 255 blue, really bright pink, if someone wanted to use pink they'd just have to not use exactly 255 red and 255 blue, 255 red and 254 blue wouldnt be picked up for example) and the game sticks the head to that spot. you could also maybe just get the height by seeing where the sprite stops in the image (checking for a transparent area that could reasonably be the wasted space above the sprite).
I think that you may be over thinking this a bit. It's not true 3D that we're dealing with, everything is still flat sprites. If you make the code to search for a specific color, such as pink, if would have to search all of the xy coordinates for the sprite until it finds it or runs out of pixels to search through for every character on the screen, for every frame per second. Here's an example of the psuedo code to do that...

First, you have to determine the body, that's stored as a variable.
Second, you have to find the dot.

dotfound=false
x=-1
y=-1
Start the first loop here and do it while y<=MaxSpriteSize and dotfound=false
x=x+1
y=y+1
Second loop runs while x<MaxSpriteSize and dotfound=false
if pixel x,y is pink then dotfound=true
x=x+1
End of second loop
if founddot is false then x=-1
End of the first loop,

mask the body
place the body
place the heads mask with the offset calculated
place the head at the same location


If things are simply lined up it's just masking and placing twice over using the same upperleft xy location. It you use a file that gives an offset xy for the head, then you just add the offset values in during the placement. Even if you narrow the location of the pink dot down to a 7x7 pixel location(which is just +/3 pixels), that's up to 49 unnecessary calculations as it checks each pixel, and that's just to draw one dude.

-Rabbit
 
I'd love it if there was a coherent tutorial for putting custom Trainer sprites in the game, since I have the spriting knowledge to make them, buuut I lack the technical knowhow to do so. ^^;
 

Gamer5

Fisherman
If we are going through with this, does it mean you won't be able to choose your trainer type like in the real games? (i.e Bug Catcher, Lass, Youngster) Like in the union rooms and on your trainer card.
 

Splint

Champion
I'd love it if there was a coherent tutorial for putting custom Trainer sprites in the game, since I have the spriting knowledge to make them, buuut I lack the technical knowhow to do so. ^^;
Step 1:
Trainer sprites sheets are 96 x 128 so 32 pixels big per sprite and will look like this
red.png


U can edit this one if u want and save it.

Step 2:
To convert the sprite to a usable format for the game u can use a program called XNA Formatter this will convert it to xnb

Available from here:
http://sourceforge.net/projects/xnbbuilder/

Step 3:
Name your file to something u like and place it in the following folder:
Pokemon3D\Pokemon\Content\Textures\NPC\

Step 4:
Go to your save folder located at Pokemon3D\Pokemon\Save\<Your Ingame Name>
open up the file named Player.dat in notepad or wordpad or any text editing program.

Inside it will look something like this

Code:
Name|Test
Position|2,0.1,2
MapFile|yourroom.dat
Rotation|4.767895
RivalName|???
Money|3000
Badges|0
Gender|Male
PlayTime|0,2,55
OT|18147
Points|0
hasPokedex|0
freeCamera|1
thirdPerson|0
skin|Red
location|Your Room
battleAnimations|1
BoxAmount|5
LastRestPlace|yourroom.dat
LastRestPlacePosition|1,0.1,3
DiagonalMovement|0
RepelSteps|0
LastSavePlace|barktown0.dat
LastSavePlacePosition|8,0.09602252,-1
The part we are interested in is this

Code:
skin|Red
All you need to do is replace "Red" with the name u have given to your xnb file.
Save it and you are done.

Note:
If u tend on using this on multiplayer the person whom you are playing co-op with needs to have this file as well before connecting to your session.
 

DracoHouston

Kolben Developer
Contributor
this is where attachments could come in, in fps games they define a point as a socket or attachment (usually just an origin and maybe direction) so things know where to go (like putting a gun in a character's hand, putting your character on top of your mount in WoW and so on). Body skins could come with a matching .dat file that says where the head goes. or you could use a pixel coloured a certain colour (say, 255 red, 0 green, 255 blue, really bright pink, if someone wanted to use pink they'd just have to not use exactly 255 red and 255 blue, 255 red and 254 blue wouldnt be picked up for example) and the game sticks the head to that spot. you could also maybe just get the height by seeing where the sprite stops in the image (checking for a transparent area that could reasonably be the wasted space above the sprite).
I think that you may be over thinking this a bit. It's not true 3D that we're dealing with, everything is still flat sprites. If you make the code to search for a specific color, such as pink, if would have to search all of the xy coordinates for the sprite until it finds it or runs out of pixels to search through for every character on the screen, for every frame per second. Here's an example of the psuedo code to do that...

First, you have to determine the body, that's stored as a variable.
Second, you have to find the dot.

dotfound=false
x=-1
y=-1
Start the first loop here and do it while y<=MaxSpriteSize and dotfound=false
x=x+1
y=y+1
Second loop runs while x<MaxSpriteSize and dotfound=false
if pixel x,y is pink then dotfound=true
x=x+1
End of second loop
if founddot is false then x=-1
End of the first loop,

mask the body
place the body
place the heads mask with the offset calculated
place the head at the same location


If things are simply lined up it's just masking and placing twice over using the same upperleft xy location. It you use a file that gives an offset xy for the head, then you just add the offset values in during the placement. Even if you narrow the location of the pink dot down to a 7x7 pixel location(which is just +/3 pixels), that's up to 49 unnecessary calculations as it checks each pixel, and that's just to draw one dude.

-Rabbit
true, i was just throwing out ideas. more calculations but they're simple ones so the fps hit could be negligible in practice.

i just dont think with the way some sprites are that you can make a system for this that looks nice with just offsets unless we use the same pose and body/head sizes for all player sprites. i kind of like the system where you can just use any valid npc sprite
 

DracoHouston

Kolben Developer
Contributor
ive been thinking about this more and the texture for npcs are loaded into an xna texture2d object (so its in memory) and when making the new npc these operations to find the special pixel would have to be done once, for 9 frames (NPCs currently only stand or walk), which can then be stored in memory as a 2d vector for easy access when drawing the head. this approach would remove the need for skins to have a companion data file with values for the offsets and allows for characters that have weird head movements because the head can be drawn at an arbitrary position every frame.
 
Status
Not open for further replies.
Top