don't click here

General Project Screenshot/Video Thread

Discussion in 'Engineering & Reverse Engineering' started by Tweaker, Jun 26, 2008.

  1. Cooljerk

    Cooljerk

    NotEqual Tech, Inc - VR & Game Dev Oldbie
    4,505
    201
    43
    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.
     
  2. LoneDevil

    LoneDevil

    Eternal Underdog Member
    [​IMG][​IMG][​IMG]
     
  3. SuperSnoopy

    SuperSnoopy

    I like Sonic Advance Member
    1,778
    740
    93
    Lyon, France
    Slice of life visual novel, coming soon...?
    Are you sure it's not a sequel to metal sonic hyperdrive :v:
     
  4. EightC

    EightC

    Member
    11
    0
    0
    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.
    [​IMG]

    Updated with base textures
    [​IMG]
     
  5. Sappharad

    Sappharad

    Oldbie
    1,413
    70
    28
    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.
    [youtube]http://www.youtube.com/watch?v=tZu4Zbf0ba8[/youtube]
    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.
     
  6. Cooljerk

    Cooljerk

    NotEqual Tech, Inc - VR & Game Dev Oldbie
    4,505
    201
    43
    So glad you came forth with this man, amazing work!
     
  7. MarkeyJester

    MarkeyJester

    Original, No substitute Resident Jester
    2,192
    406
    63
    Japan
    [​IMG]
     
  8. MarkeyJester

    MarkeyJester

    Original, No substitute Resident Jester
    2,192
    406
    63
    Japan
    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:

    [​IMG]
    [​IMG]

    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.
     
  9. Cooljerk

    Cooljerk

    NotEqual Tech, Inc - VR & Game Dev Oldbie
    4,505
    201
    43
    ZOMG petition to ban MJ! :P

    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.
     
  10. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,735
    334
    63
    SonLVL
    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.
     
  11. Clownacy

    Clownacy

    Tech Member
    1,053
    581
    93
    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.
     
  12. Cooljerk

    Cooljerk

    NotEqual Tech, Inc - VR & Game Dev Oldbie
    4,505
    201
    43
    Perhaps a better format than bmp would be gif, then? Or some other paletted format.

    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.
     
  13. Clownacy

    Clownacy

    Tech Member
    1,053
    581
    93
    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.
     
  14. MarkeyJester

    MarkeyJester

    Original, No substitute Resident Jester
    2,192
    406
    63
    Japan
    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.

    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.

    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=

    Yeah, once again, I apologise, I worded it wrong (as explained above).
     
  15. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,735
    334
    63
    SonLVL
    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.
     
  16. RikohZX

    RikohZX

    Member
    1,011
    281
    63
    [​IMG][​IMG][​IMG]
    [​IMG][​IMG][​IMG]


    Mania's HUD is easy to modify, but hard to hone down. Especially given a lot of size boundary quirks, such as with Zone names being made with the default large font in mind, or the end-of-act number being rather stingy in small space.
     
  17. MarkeyJester

    MarkeyJester

    Original, No substitute Resident Jester
    2,192
    406
    63
    Japan
    I know majority of SonicRetro wasn't really interested when I released a previous version of this sound driver, but some of you took an interest.

    So rather than bumping the thread, I figured I'd post it here instead.

    https://www.youtube.com/watch?v=hP45A0pTVLQ

    Enjoy~
     
  18. Devon

    Devon

    Down you're going... down you're going... Tech Member
    1,218
    1,374
    93
    your mom


    Yeah, I know the actual logo itself kinda looks like crap right now. I'll clean it up later. I just wanna show off how it animates.
     
  19. roachdaripper

    roachdaripper

    Source Engine Junkie Member
    35
    0
    0
    Wales
    Trying not to rage when porting SADX/SA2 models on PC.



    Back about a year ago when I first started animating for the Source Engine, I pulled a model from the models resource, and that model happened to be one of the bosses from Sonic 4 Episode 1.
    (About the only thing on my entire Youtube channel that's related to Sonic really, I've been recently attempting to port other models from games like Adventure DX, and Adventure 2, but they've been fruitless so far, so enjoy my crappy animations)

    EDIT: the [media] tag apparently only accepts the http tag, as opposed to the https tag. :v:
     
  20. Devon

    Devon

    Down you're going... down you're going... Tech Member
    1,218
    1,374
    93
    your mom
    Oops I forgot to post this here...



    Sonic's Fun and Easy Adventure, coming to the Hacking Expo! It'll be super easy and ultra fun for the whole family! :)