Sonic and Sega Retro Message Board: General Project Screenshot/Video Thread - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
  • 318 Pages +
  • ◄ First
  • 307
  • 308
  • 309
  • 310
  • 311
  • Last ►
    Locked
    Locked Forum

General Project Screenshot/Video Thread

#4621 User is offline Cooljerk 

Posted 01 September 2017 - 07:33 AM

  • NotEqual Tech, Inc - VR & Game Dev
  • Posts: 4198
  • Joined: 06-April 06
  • Gender:Male
  • Wiki edits:9

View PostChimera, on 01 September 2017 - 06:43 AM, said:

oooohhh this looks neato. Definitely interested in where this goes.

Emerald hill with a purple tinge looks really pretty tbh.


It was sort of just a coincidence that it wound up that color. Its not obvious, but that was a test for a script to handle palette rotation, the blue subchannel for those palette enteries were increasing (or decreasing) every frame as a test of the script.

The blues for the waterfall also were rotating, albeit once every two frames. Again, just testing the script.
This post has been edited by Cooljerk: 01 September 2017 - 07:34 AM

#4622 User is offline LoneDevil 

Posted 01 September 2017 - 03:03 PM

  • Posts: 128
  • Joined: 09-December 13
  • Gender:Male
  • Project:Metal Sonic Rebooted
Posted ImagePosted ImagePosted Image

#4623 User is offline SuperSnoopy 

Posted 01 September 2017 - 03:08 PM

  • I prefer Sonic Advance to Sonic 2
  • Posts: 306
  • Joined: 29-June 17
  • Gender:Male
  • Location:France
  • Project:Learning how to fucking draw
Are you sure it's not a sequel to metal sonic hyperdrive :v:

#4624 User is offline EightC 

Posted 01 September 2017 - 06:03 PM

  • Posts: 11
  • Joined: 01-September 17
  • Gender:Male
First I would just like to say hello, I'm new to the forums. I've been looking through this thread for awhile now and there is some incredible stuff that everyone is working on.

I've been wanting to experiment with recreating some of the older Sonic stages in 3D and eventually getting something up and running in either Unreal or Unity (not sure yet). I've decided to start with a smaller test area by doing some assets from Scrap Brain Zone from Sonic 1. Much like sprite tile sets my goal is to build modular pieces like these to put the stage itself together. I've only just started but I've finished up my first tile and thought I would share my work and continuing progress.

This image shows the original asset, my baked AO (ambient occlusion) and just a quick test rendered in Marmoset Toolbag with the normal map applied.
Posted Image

Updated with base textures
Posted Image
This post has been edited by EightC: 02 September 2017 - 01:05 AM

#4625 User is offline sonicblur 

Posted 01 September 2017 - 06:16 PM

  • Posts: 1202
  • Joined: 18-February 08
  • Gender:Male
  • Wiki edits:6
I'm still debating to what extent and when the finished version of this should be released, but Cooljerk wanted me to post about it publicly because he's been hinting at its existence a few times now so here it is.

This is one of the first builds I had running on Dreamcast, the video is from mid-July. The serious graphical issues are due to memory constraints on the DC and crap I stripped out just to get it to fit. The rendering code has been mostly re-written since then to use hardware palettes on the DC, which reduces texture memory use to 1MB but I haven't actually finished hooking it up.
The SDL / macOS build supports file redirection natively, similar to what MainMemory just did for Mania. No SDL / Windows build yet, but that was never the point.

This doesn't get worked on very often, and I was actually hoping to finish for the 5th anniversary last year but did not. It probably won't be done this year either, and I still need to decide if including the source is a really bad idea or not. It's C like the originals, specifically so it could easily be ported to Dreamcast.

Edit: Just to clarify, this stuff will not really help with Mania at all. The stage format, byte code opcodes, config format, etc. have all changed.
This post has been edited by sonicblur: 02 September 2017 - 11:47 AM

#4626 User is offline Cooljerk 

Posted 02 September 2017 - 07:31 AM

  • NotEqual Tech, Inc - VR & Game Dev
  • Posts: 4198
  • Joined: 06-April 06
  • Gender:Male
  • Wiki edits:9

View Postsonicblur, on 01 September 2017 - 06:16 PM, said:

I'm still debating to what extent and when the finished version of this should be released, but Cooljerk wanted me to post about it publicly because he's been hinting at its existence a few times now so here it is.

This is one of the first builds I had running on Dreamcast, the video is from mid-July. The serious graphical issues are due to memory constraints on the DC and crap I stripped out just to get it to fit. The rendering code has been mostly re-written since then to use hardware palettes on the DC, which reduces texture memory use to 1MB but I haven't actually finished hooking it up.
The SDL / macOS build supports file redirection natively, similar to what MainMemory just did for Mania. No SDL / Windows build yet, but that was never the point.

This doesn't get worked on very often, and I was actually hoping to finish for the 5th anniversary last year but did not. It probably won't be done this year either, and I still need to decide if including the source is a really bad idea or not. It's C like the originals, specifically so it could easily be ported to Dreamcast.


So glad you came forth with this man, amazing work!

#4627 User is offline MarkeyJester 

Posted 22 September 2017 - 02:43 PM

  • It's Saturday TV Toons!! (90's Style)
  • Posts: 1854
  • Joined: 22-July 08
  • Gender:Male
  • Location:Japan
  • Wiki edits:16
Posted Image

#4628 User is offline MarkeyJester 

Posted 02 October 2017 - 08:31 AM

  • It's Saturday TV Toons!! (90's Style)
  • Posts: 1854
  • Joined: 22-July 08
  • Gender:Male
  • Location:Japan
  • Wiki edits:16
Double post, but it's not my fault if no-one wants to comment (they had 10 days to do it so...).

Here is a little tool I've been working on:

Posted Image
Posted Image

What it will do, is extract the sprites of Sonic games, and export them into bitmap frames/files. I'll later make another program that will convert them back into art, map and plc files. What this will mean, is that you can edit the art in paint or whatever bitmap/png editing tool you want, and just run a tool to convert it all. This should eliminate the tedious need to handle importing tiles and so forth, at least for the instances that aren't necessary, like, editing characters. The fact that the frames are in separate files should allow you to control the positioning of the art relative to the object's position.

With compression applied, we could also support stuff like... monitors, rings, badniks, etc.. In fact, how would you guys feel to having all art in the disassembly as bitmap/png files? I'm sure that'd make art editing easier for many. The tool should handle optimising the data best for art/sprites, and with certain options enabled, you should be able to control how it's optimised.
This post has been edited by MarkeyJester: 02 October 2017 - 08:32 AM

#4629 User is offline Cooljerk 

Posted 02 October 2017 - 09:33 AM

  • NotEqual Tech, Inc - VR & Game Dev
  • Posts: 4198
  • Joined: 06-April 06
  • Gender:Male
  • Wiki edits:9

View PostMarkeyJester, on 02 October 2017 - 08:31 AM, said:

Double post, but it's not my fault if no-one wants to comment (they had 10 days to do it so...).


ZOMG petition to ban MJ! :P

Quote

I'll later make another program that will convert them back into art, map and plc files. What this will mean, is that you can edit the art in paint or whatever bitmap/png editing tool you want, and just run a tool to convert it all. This should eliminate the tedious need to handle importing tiles and so forth, at least for the instances that aren't necessary, like, editing characters. The fact that the frames are in separate files should allow you to control the positioning of the art relative to the object's position.

With compression applied, we could also support stuff like... monitors, rings, badniks, etc.. In fact, how would you guys feel to having all art in the disassembly as bitmap/png files? I'm sure that'd make art editing easier for many. The tool should handle optimising the data best for art/sprites, and with certain options enabled, you should be able to control how it's optimised.


My own editor actually does some of this stuff -- it's what we were supposed to be using to make that art you asked me about a long while ago haha. If you'd like, I'd be more than happy to share my stuff with you to roll into your image editor.

#4630 User is offline MainMemory 

Posted 02 October 2017 - 12:54 PM

  • Every day's the same old thing... Same place, different day...
  • Posts: 4199
  • Joined: 14-August 09
  • Gender:Not Telling
  • Project:SonLVL
  • Wiki edits:1,339
SpriteSheetGen and SpritePlotter.NET can be used to accomplish similar results, albeit using a sprite sheet instead of individual images. It writes the center points of each sprite to a separate 2-color image.

I really hate to feel like I'm stepping on your toes, but I could probably add an option for separate image files to my programs.

As for having it set up like that in the disassembly, I can see how it could be useful, but good luck convincing anyone to switch.

#4631 User is offline Clownacy 

Posted 02 October 2017 - 04:40 PM

  • Posts: 718
  • Joined: 06-July 13
  • Gender:Not Telling
I don't think replacing a disassembly's files with bitmaps is such a good idea. That would make the importer an automatic build-time tool, wouldn't it? If that's the case, then how does the user decide which palette a spriteset should use, and how would they know how many tiles/sprites it uses once converted?

I imagine the former would be solved through the use of 'project' files, like what SonLVL and PlaneEd use, but by practically hiding the existence of palettes from the user like that, I think you might be unintentionally tricking new hackers into thinking the palette limit doesn't exist, only for them to be confused when their new Manic sprite isn't green. Sure, once they figure out that palettes are a thing, they won't make that mistake again, but exactly when will that happen? As a standalone tool that doesn't load project files, the user would *have* to select a palette before any images will convert in the first place, averting the issue entirely, but having a prompt like that for every spriteset is simply not feasible when it's an automatic tool that batch-converts hundreds of files every time you build the ROM.

As for my other concern, hiding the details of how many tiles/sprites a converted spriteset uses is a problem even for experienced hackers, as their ability to strictly monitor and control VRAM/sprite usage is basically crippled. Maybe if the tool outputs converted files to a temporary folder, or produces a log file of every frame of every spriteset, that gives people some way of getting the information, but that seems awfully inconvenient for a program that's all about convenience.

With all that said, I think the importer would be better off not being a part of the disassembly's build process, and the user should just use it separately like any other tool: exporting sprites once, and then reimporting them whenever they make changes. The user can select the palette file for the particular spriteset they're editing, and the tool can tell the user the number of tile/sprites that same spriteset uses once conversion is complete. Not to mention it means the disassembly is still accessible to people who prefer to edit sprites a different way.

#4632 User is offline Cooljerk 

Posted 02 October 2017 - 04:48 PM

  • NotEqual Tech, Inc - VR & Game Dev
  • Posts: 4198
  • Joined: 06-April 06
  • Gender:Male
  • Wiki edits:9

View PostClownacy, on 02 October 2017 - 04:40 PM, said:

I don't think replacing a disassembly's files with bitmaps is such a good idea. That would make the importer an automatic build-time tool, wouldn't it? If that's the case, then how does the user decide which palette a spriteset should use,


Perhaps a better format than bmp would be gif, then? Or some other paletted format.

Quote

and how would they know how many tiles/sprites it uses once converted?


Well isn't that part of the point? That people wouldn't have to worry about that, since it's handled for them? The packing tool he's describing could display that information at compile time.

#4633 User is offline Clownacy 

Posted 02 October 2017 - 05:28 PM

  • Posts: 718
  • Joined: 06-July 13
  • Gender:Not Telling
I already mentioned displaying information at build time, but said it seemed inconvenient. I think converting a single set of images, and then being told however many tiles and sprites it takes, is more intuitive and straightforward than having to search through a big log file that's only produced when you build the ROM.

The thing with VRAM/sprite consumption is that it's not something you can just ignore. The Mega Drive only has so much VRAM, and you have to keep on top of how much of that limited space your sprites are using. For example, using too many tiles for Sonic in S1 will make him load the points graphics in-game instead, because the mappings are reading from beyond his tile limit. Likewise, there's a limit on how many sprite pieces the game can draw before it just stops.

As for using GIF images, those can be tricky to edit if the user doesn't know what they're doing, which I think takes away from the tool's goal of simplifying sprite editing. I use GIMP for image editing, and when you edit an indexed image, it forcefully limits what colours you can use, but it does so in a pretty confusing way: say I have a file with a palette consisting of while, blue, red, and black, and I try to draw a yellow line - GIMP will let me select the colour yellow, but when I try to draw, it will draw a red line.

Having the bitmaps contain palette data makes sense for exported images, but if a user tries to create their own set of files from the ground up, they'd have to add the palette data themselves, again making things more difficult than I think they really need to be.

When I wrote that last post, I didn't notice that _Palette.bmp file. That might actually solve my palette issue, now that I think about it: if you're editing Sonic's sprites, then you must have looked in that folder, and since the palette file is the very first one listed (if sorted by name), chances are you'll know it's there. I'm not sure how it would work if you were to edit it though. If you edited the palette bitmap, and then reimported the folder, would it overwrite the actual palette file? In that case, wouldn't the palette bitmap used by other sprites that used the same original file become outdated? Even if editing the palette bitmap doesn't do anything, what if you edit the original palette file? Now all the palette bitmaps are outdated.
This post has been edited by Clownacy: 02 October 2017 - 05:33 PM

#4634 User is offline MarkeyJester 

Posted 02 October 2017 - 07:45 PM

  • It's Saturday TV Toons!! (90's Style)
  • Posts: 1854
  • Joined: 22-July 08
  • Gender:Male
  • Location:Japan
  • Wiki edits:16
Well actually, the tool is not meant to convert everything at assembly time. What you will have, is a batch file in that folder for example, which calls the compactor program, and packs all of those bitmap frames into art, plc, etc... But, you only run the batch to compact it all, when you make a change, if you don't. You don't need to compact, because there will already be art, plc, etc from the last time it was compact. The assembly will do what it has always done, and no more, the compacting process is independant of the assembly process. Each sprite set will have its own folder of palette, art frames and sprite include list (to ensure the sprites are compacted in the order they are required), and a batch file. You make an edit to a monitor frame art, run the batch, and it'll compact just the monitor frames into their art, plc, map, so forth. Not every single art set, and certainly not at assembly time. Once you made your changes, and ran that batch to compact it, you won't need to run it again, unless you make another change to that specific art set.

As for the whole palette thing, and other misc things that may or may not confuse new comers, well, that's all up for debate, what you see is not a final decision, it's merely a developement of practice. The tool will accept .bin files with Mega Drive palettes too. I just prefer bmp. You don't HAVE to have a bitmap palette... These tools aren't meant to solve every problem known here, they're just meant to help ease a few at the possible cost of creating some minor other issues. At any rate, it's better than having fuck all, at least you'd have the choice.

I also apologise, I worded my intentions wrong. I wasn't intending on getting any public disassemblies to outright change to this new system. I only meant supplying a tool so that anyone who wants to do it, can apply it to their current disassemblies/sources as they see fit. This is why I'm writing an extractor first, followed by the compactor afterwards. I wouldn't dare change our public disassemblies to handle this, first you'd have the issue of making sure the data compacts 1:1 to the original. Secondly, some people would prefer to handle the tiles, art, etc, with specific control. Applying this would make it easier for noobs at the expense of making it harder for experienced individuals, I certainly would prefer to avoid that thank you.

View PostMainMemory, on 02 October 2017 - 12:54 PM, said:

SpriteSheetGen and SpritePlotter.NET can be used to accomplish similar results, albeit using a sprite sheet instead of individual images. It writes the center points of each sprite to a separate 2-color image.
Yes, I know this, I made the original SpritePlotter of which your SpritePlotter.NET is based on, remember? The problem is, there's no way to control the centre position of each frame, that's why I'm opting for this new method where the frames are seperate images, the object's central position itself will be the centre of the bitmap/png, thus allowing us to place the sprites in specific positions relative from the centre.

View PostMainMemory, on 02 October 2017 - 12:54 PM, said:

I really hate to feel like I'm stepping on your toes, but I could probably add an option for separate image files to my programs.
Well, the thing is.

I make GetArt... You make GetArt.NET
I make SpritePlotter... You make SpritePlotter.NET
I make something functional with a principle good idea, to get the idea out there... You effectively improve on it, and make a better more stable version.

There is nothing wrong with improving on resources to help people out, we're here as a community to help each other, I have no problem with you doing that, just as long as you give me time to actually make it and set the ground rules first d=

View PostMainMemory, on 02 October 2017 - 12:54 PM, said:

As for having it set up like that in the disassembly, I can see how it could be useful, but good luck convincing anyone to switch.
Yeah, once again, I apologise, I worded it wrong (as explained above).

#4635 User is offline MainMemory 

Posted 02 October 2017 - 10:32 PM

  • Every day's the same old thing... Same place, different day...
  • Posts: 4199
  • Joined: 14-August 09
  • Gender:Not Telling
  • Project:SonLVL
  • Wiki edits:1,339
As I mentioned in my post, I have provided a method for defining the center point of each frame, by means of a separate image with a pixel marking each sprite's center. It's not foolproof, but it works well enough most of the time. It's what I used for Tikal's sprites in KEH.

But yeah, your way would have its own unique benefits, and I will wait until you have something finished before I decide if I want to copy it shamelessly.

  • 318 Pages +
  • ◄ First
  • 307
  • 308
  • 309
  • 310
  • 311
  • Last ►
    Locked
    Locked Forum

2 User(s) are reading this topic
0 members, 2 guests, 0 anonymous users