(09-30-2015, 10:47 PM)DarkGrievous7145 Wrote: I cannot explain this in-depth,but the basic process would be this:

First, you would render the models at a certain angel, probably with some form of parallel projection, like isometric. For sonic, you'd probably want a side view. You'd ideally want a transparent background, as well.

You may or may not want to disable the anti-aliasing feature, as well... assuming this is really possible, some programs don't like to. You'd almost certainly want to do this for older systems. I can't say much about newer ones. If you were targeting mobile devices or personal computers, probably not an issue.

making it work on real consoles is something else entirely. The games for older consoles generally were some form of arbitrary binary file, from what I understand. Can't say there's a one size fits all for them. Odds are you'll need to look-up the graphical and processing limitations of these consoles, and find the tools (if any) to mod or home-brew roms for them. That said, you are certainly going to need to know the color and tile/sprite size limitations of the older consoles as well.

Finally, seeing as the old games/systems don't follow any strict guidelines about development or structure... there probably will be some degree of programming, and/or hacking, involved. Sprites were not stored in any form of universal file format for quite some time. rather, they were sections of binary data within the game file itself, and probably had the palettes separate from the actual graphic, as well. (even newer consoles tend to follow this rule)
So, you could save, let's just say a 4x4 white square with a black outline, and then

so, bytes (values in hexadecimal) for this image could be:
palette = ff ff ff 00 00 00
graphic = 01 01 01 01 01 00 00 01 01 00 00 01 01 01 01 01

palette entries are each three bytes, one byte for every primary color
If you were making a game from scratch, there is a very real possibility you'll be writing the code to handle this from scratch. (which most likely will include assembly code to read data at certain offsets, sounds fun, right?) On the other hand, if you're modding an already existing rom, you could probably use a hacking utility to insert the data for you.

Hope this is somewhat useful?
A lot of what you're asking is very heavily dependent on the target system, and even the game series, or developers.
I base my answer on what information I have found or researched on this particular topic. Your best bet is to first see what and of the capabilities of doing what you've suggested are, then if you're up to it, getting all the necessary tools/resources to do it. I have backed-out of numerous projects of a similar nature because in the long run, making a new game from scratch, with something like C , C++, C#, Python, Flash, Shockwave, Unity, HTML5 , <insert engine/language/tech here>, is probably infinitely times easier than modding or cloning an existing game for the same platform it was originally released on. Not to say it's impossible, but you're in for one long and bumpy ride if you do this. The most successful projects and artists with a goal like this in mind have spent a fairly decent amount of time, and sometimes, money, making it happen!

(09-30-2015, 11:25 PM)CpChan Wrote:

(09-30-2015, 10:47 PM)DarkGrievous7145 Wrote: I cannot explain this in-depth,but the basic process would be this:

First, you would render the models at a certain angel, probably with some form of parallel projection, like isometric. For sonic, you'd probably want a side view. You'd ideally want a transparent background, as well.

You may or may not want to disable the anti-aliasing feature, as well... assuming this is really possible, some programs don't like to. You'd almost certainly want to do this for older systems. I can't say much about newer ones. If you were targeting mobile devices or personal computers, probably not an issue.

making it work on real consoles is something else entirely. The games for older consoles generally were some form of arbitrary binary file, from what I understand. Can't say there's a one size fits all for them. Odds are you'll need to look-up the graphical and processing limitations of these consoles, and find the tools (if any) to mod or home-brew roms for them. That said, you are certainly going to need to know the color and tile/sprite size limitations of the older consoles as well.

Finally, seeing as the old games/systems don't follow any strict guidelines about development or structure... there probably will be some degree of programming, and/or hacking, involved. Sprites were not stored in any form of universal file format for quite some time. rather, they were sections of binary data within the game file itself, and probably had the palettes separate from the actual graphic, as well. (even newer consoles tend to follow this rule)
So, you could save, let's just say a 4x4 white square with a black outline, and then

so, bytes (values in hexadecimal) for this image could be:
palette = ff ff ff 00 00 00
graphic = 01 01 01 01 01 00 00 01 01 00 00 01 01 01 01 01

palette entries are each three bytes, one byte for every primary color
If you were making a game from scratch, there is a very real possibility you'll be writing the code to handle this from scratch. (which most likely will include assembly code to read data at certain offsets, sounds fun, right?) On the other hand, if you're modding an already existing rom, you could probably use a hacking utility to insert the data for you.

Hope this is somewhat useful?
A lot of what you're asking is very heavily dependent on the target system, and even the game series, or developers.
I base my answer on what information I have found or researched on this particular topic. Your best bet is to first see what and of the capabilities of doing what you've suggested are, then if you're up to it, getting all the necessary tools/resources to do it. I have backed-out of numerous projects of a similar nature because in the long run, making a new game from scratch, with something like C , C++, C#, Python, Flash, Shockwave, Unity, HTML5 , <insert engine/language/tech here>, is probably infinitely times easier than modding or cloning an existing game for the same platform it was originally released on. Not to say it's impossible, but you're in for one long and bumpy ride if you do this. The most successful projects and artists with a goal like this in mind have spent a fairly decent amount of time, and sometimes, money, making it happen!

Thank you very much, this helps a lot! Do you happen to have any visual guides on setting palettes and whatnot? I'm not too knowledgeable when it comes to spritework and how visual data works on older consoles. I'm also looking for more info on the process of actually creating the visual style, if you have any more information or a suggestion as to what program to use. I'm targeting a 16-bit look like so:

(10-01-2015, 12:22 AM)DarkGrievous7145 Wrote:

(09-30-2015, 11:25 PM)CpChan Wrote:

(09-30-2015, 10:47 PM)DarkGrievous7145 Wrote: I cannot explain this in-depth,but the basic process would be this:

First, you would render the models at a certain angel, probably with some form of parallel projection, like isometric. For sonic, you'd probably want a side view. You'd ideally want a transparent background, as well.

You may or may not want to disable the anti-aliasing feature, as well... assuming this is really possible, some programs don't like to. You'd almost certainly want to do this for older systems. I can't say much about newer ones. If you were targeting mobile devices or personal computers, probably not an issue.

making it work on real consoles is something else entirely. The games for older consoles generally were some form of arbitrary binary file, from what I understand. Can't say there's a one size fits all for them. Odds are you'll need to look-up the graphical and processing limitations of these consoles, and find the tools (if any) to mod or home-brew roms for them. That said, you are certainly going to need to know the color and tile/sprite size limitations of the older consoles as well.

Finally, seeing as the old games/systems don't follow any strict guidelines about development or structure... there probably will be some degree of programming, and/or hacking, involved. Sprites were not stored in any form of universal file format for quite some time. rather, they were sections of binary data within the game file itself, and probably had the palettes separate from the actual graphic, as well. (even newer consoles tend to follow this rule)
So, you could save, let's just say a 4x4 white square with a black outline, and then

so, bytes (values in hexadecimal) for this image could be:
palette = ff ff ff 00 00 00
graphic = 01 01 01 01 01 00 00 01 01 00 00 01 01 01 01 01

palette entries are each three bytes, one byte for every primary color
If you were making a game from scratch, there is a very real possibility you'll be writing the code to handle this from scratch. (which most likely will include assembly code to read data at certain offsets, sounds fun, right?) On the other hand, if you're modding an already existing rom, you could probably use a hacking utility to insert the data for you.

Hope this is somewhat useful?
A lot of what you're asking is very heavily dependent on the target system, and even the game series, or developers.
I base my answer on what information I have found or researched on this particular topic. Your best bet is to first see what and of the capabilities of doing what you've suggested are, then if you're up to it, getting all the necessary tools/resources to do it. I have backed-out of numerous projects of a similar nature because in the long run, making a new game from scratch, with something like C , C++, C#, Python, Flash, Shockwave, Unity, HTML5 , <insert engine/language/tech here>, is probably infinitely times easier than modding or cloning an existing game for the same platform it was originally released on. Not to say it's impossible, but you're in for one long and bumpy ride if you do this. The most successful projects and artists with a goal like this in mind have spent a fairly decent amount of time, and sometimes, money, making it happen!

Thank you very much, this helps a lot! Do you happen to have any visual guides on setting palettes and whatnot? I'm not too knowledgeable when it comes to spritework and how visual data works on older consoles. I'm also looking for more info on the process of actually creating the visual style, if you have any more information or a suggestion as to what program to use. I'm targeting a 16-bit look like so:

sadly, no..
i can't even find such things...

all i can really say is google it...
maybe you'll find a 16-bit color palette...maybe
but my experiences with that have taught me a lot of the palettes don't exactly exist in any use-able format.
(Or if they do, i cannot find them)

I see with this image in particular you have some dithering going on.
(so, let's say the system didn't support gray)
2x2 pixels:
white,black
black,white
there's a basic example, if you weren't already familiar with this.
Depending how closely you want to mimic the style, definitely want to try including that, as well.
(that is an official screenshot or made from official sprites, right?)