Are you guys not reading or something? It's 256 colors per line; in other words, only using the colors you need. Such a method is much more optimized and ideal than using mindlessly bloated 3D methods or using a full 32-bit color palette that has millions of colors. This is both closer to the original Sonic engine's workings, and is actually making conservative use of hardware, unlike most modern games these days.
Actually, I'm pretty sure the Needlemouse engine was using individual palettes for each Object/Graphical surface not per line. Also, the actual frame buffer itself would be at least 16bits to accommodate the use of these different palettes simultaneously on screen. Drawing these graphics is technically slower than directly copying Graphic data of the same bit depth, since you have to look up the colour from the palette table first before copying the data to the frame buffer. Using 3D acceleration isn't mindlessly bloated, since it's effectively getting a massive performance boost for free. It's remarkably simple to draw textured polygons to the screen, it's not like you're going to have to include typical 3D engine fare like a scenegraph and all that. I'm not saying that's what this project has to use, just that your reasoning behind what counts as 'optimised' is unfounded. EDIT: I should probably emphasize that I'm talking in terms of rendering speed here. There's always a trade off between memory consumption and performance in graphics. Having palettised graphics on a higher depth surface takes longer, but saves memory by storing the graphics in 8bit, also allowing the same graphic to be reused with different colours. ANOTHER EDIT: Also, has anyone considered this? The sprites are to be 4x, looking good baby. Now not everyone will be pumping out a huge screen res to take advantage of this... no problem, we'll have scalability. Here's the problem, the sprites will look crap without filtering and blended edges. Doing real time filtered scaling and blending in pure software will RAPE performance, especially if you have to look up colors from palettes. You could store the graphics pre-scaled... but that's not possible with filtering, since the color palette limit will probably be broken.
The only time pallets should be used is when you are running in a low-color video mode with hardware support for pallets. Doing bit-for-bit color lookups on textures will be very slow. Especially with larger textures to worry about. You can forget about filtered scaling. You could maybe get away with nearest-neighbor, but the artifacts will be ugly.
Just to let you guys know what I'm up to. I've been working on a generic 2D platformer tool-chain. Primarily a map editor at this point with support for higher resolution assets. If I get it to a usable state I'd be willing to demo it here. I use 2D scenegraphs to store map data, which isn't the same type of map used in Sonic 2, but is flexible enough to make reproductions.
I'll have to talk to Cooljerk about it, but one of the main ideas I had is that the data is *stored* in a paletted image (with an added alpha channel for smoothing and such) and then during load is converted into a 32-bit image for actual use by the engine. The 32-bit assets would be reconverted whenever the palette is changed. A system could be developed to ensure that *only* the assets that need to be reconverted are converted. There are plenty of ways to deal with things like this, and they'll be figured out in the course of development. It's good that these issues are being discussed now though. Keep it up
Yeah, well, mindblowing system, but if the engine actually works that way you might as well just use 32bit color palettes and forget about the real-time color conversion. Honestly, I don't see what's the point of using limited palettes if they are going to be emulated anyway. And yeah, Taxman has a point. Rendering decent and filtered scaled sprites by software isn't going to be fast...
Copied from my post in the level art thread, realised it's probably not the best place to put it after submitting it. ----- I came across a load of problems when trying to build a graphics engine for my own project (which was going to be OpenGL based, no palette and using more layers than the original to allow for an effects layer (such as glows overlaying over sonic when he stands behind a light)). So I was wondering, yes I've read quite a bit of various threads in here about it, if you could enlighten me on how you plan to overcome certain hurdles. 1.) Alpha channel. You say the system supports an Alpha channel (it better had or all the work so far has been for nought), is this implemented via an alpha mask or as part of the image? If it's part of the image, how do you determine what palette colour is becoming transparent. If it's a mask you need to go back to the drawing board on the people submitting vector images. 2.) Palette. You have chosen to use 10x 256 colour palettes, I can tell you now that's not enough (from experience). Limit the colours people are using in their art by all means, but if my best guess is correct, just in the artwork that has been created for Emerald Hill so far you go way beyond 2560 colours. The anti-aliasing of the vectors curves is adding possibly hundreds of colours to any given item. If you stick to the palettes then people will need to bare in mind that they can only use 10 times the amount of colours used in the original sprite including the colours used for anti-aliasing. Could I also add the suggestion of adding a separate layer for simple lighting effects that only overlay the sprite and level map layers (not the paralax background layers). As much as you are aiming for a pristine recreation of Sonic 2 at a higher resolution, I feel it would be an easily workable and worthwhile addition and wouldn't need complicated artwork. (If you would like a more accurate description of what I mean then I will post it)
Hey jman, I'm not entirely clear on where you are focusing on with development. It sounds like you are writing backend code, but I'd like to know where you are on that. Do you have existing code, or are you writing from the ground up? Where are you in terms of design right now?
As I've stated, due to current commitments I'm not going full-ahead with the backed coding yet. I will make a quick dirty engine test later on once I collaborate with Cooljerk to use his engine. That should be coming soon. As for design, I'm still trying to design ideas and ways to handle the HD assets, but beyond that it's basically looking at Sonic 2's code and translating that to C++
BTW guys: Feel free to code your own engines. The greater the competition, the greater the motivation. The goal is to replicate every feature in Sonic 2 except the bugs. So if the game uses animated palettes for something, and you plan on not supporting palettes - you better be prepared to have an alternate solution on hand.
I have no problem with using palettes, I just think the team have way underestimated the number of colours they will need. Really, the coding behind the graphics engine should be set in stone before the artwork becomes anything like it's finallized stuff. They should already be using placeholders and example art to make sure the engine can handle what they intend to use it for and start ironing out all the bugs. The alternative is that they find a problem part way through everyone creating artwork for it and then all that work has to be thrown or heavily tweaked. An additional problem I thought of earlier today was regarding tiles. All the art is being drawn as full finished objects, so we can do the same tiling tricks S2 has (repeated tiles, flipping tiles, etc.) because each small segment of the object may be slightly different making it worthless to cut them up. I'm still waiting on a reply to my previous post in this thread (or the similar one I copied these bits from) from CoolJerk as I'd hate to see this fall to pieces for the same reasons mine did. Also, regarding palette swapping, (e.g. super sonic) you are going to have to replace what, anything up to 512 colours/frame? (and have to come up with the colours you are replacing with) and still make the anti-aliasing between vector segments look nice. That's a lot of work on the programmers side that these days would be the artists responsibility. As it is we're already making the artwork with our own individual palettes, loosely at best, based on the original colours.
It would be interesting to have someone take a look at all the art submitted so far and determine the color usage so far, it could be that even sonic alone with all that fancy shmancy lighting fx is already taking up enough colors to make palettes an issue. EDIT: but I agree with Acaeris, that the problem needs to be sorted out soon because our artists are doing a wonderful job submitted high quality work, and it would be a shame to have to tell them to redo a lot of stuff, it could be a morale loss that are harmful to community projects like these.
The engine needs to be hardware accelerated. Here are the advantages and disadvantages: + Massive performance boost and far less processor dependent. + Scaling and Rotation are essentially free and of high quality. + Being able to scale the resolution of the game would be much easier and of higher quality too. Scaling 1280x960 to 1024x768 wouldn't look too good in software unless the scaling algorythm was good, but that incurs a considerable performance hit. + Can use pixel shaders to emulate Raster effects like underwater warp and other effects that may be useful in the future (depending on how purist you want to be). + Supports 32bit colour artwork. Sure, we may be using a small amount of colours (roughly the Mega Drive palette) but that isn't what makes it useful. The 8 bits of Alpha do. This can be done in software but lets face it; the performance cost would be rather high and being able to just use PNGs for the artwork allows testing of new artwork much easier. - Can't easily manipulate palettes. However this could also be remedied by creating hue maps for sprites or just creating alternate sprites/level artwork. This is a common problem with the Doom and Duke 3D sourceports and has been remedied using both methods. - Possibly more difficult to program compared to a 2D engine. This entirely depends on the programmers previous experience however. The advantages outweigh the disadvantages considerably. Theres a reason why even 2D games are hardware accelerated nowadays (such as all of PopCaps library), it's simply more effecient, faster and comes with a bunch of neat bonuses.
One of the main points of a port is portability. If anything, the graphic engine should be very separate from the main code, so you can have both software and hardware-accelerated graphics engines.
I wasn't really debating that point, I was specifically talking about the graphical side. If you're talking about portability between platforms, then using OpenGL/SDL would make it pretty easy.
It's a novel idea, but I wouldn't call portability a top priority. I think it's safe to assume that most people are using Windows based machines with Directx9 level video hardware. (cue nerd rage)
Just because the engine is going to be replicated, it doesn't mean it has to be restricted to the original restrictions as well. While some, like using 16x16 tiles (or an equivalent) are going to be unavoidable, I wouldn't go for 8x8 tiles for the objects - mappings can be replaced with a different system. Remember that a true port shouldn't be an emulator. And yeah, portability definitively is important, no matter if the priority right now is to get something working on a specific platform.
No matter what size of tile you refer to, the artwork isn't being drawn to a tile, it's been drawn as completed objects. I'm sorry if it's been detailed in this thread but I don't know whether NeedleMouse is tile or object based. If it's tile based, it'll basically cut up the objects just to piece the exact same separate pieces back together again, they won't be useable in any other object (except maybe incredibly simple pieces like the block pattern in EH).
Yeah, but it would be better to design the game with portability in mind from the very beginning, rather than put a load of work in and want to port it later, but your code is very system specific. It shouldn't be difficult to keep portability in mind as you design, right? I think it would be great if at the end of the project, there are windows, mac, and linux versions available.
Oh my god, seconded. If what I've heard about it being optimized so slower machines can also run it is true, this is a moot point as I have a perfectly working Windows 2000 virtual machine that can handle some older games and stuff. But if it's going to have high system requirements, at least have a Linux and Mac port. I'm tired of having to run shit through WINE or at 1/100th speed inside a VM. Not that, you know, I have any say in what goes on. I'm rooting for you guys from the sidelines though! (Though perhaps I should try my hand at something, see if I can help...)
