Discussion in 'Fangaming Discussion' started by Andrew75, Apr 25, 2013.
Haha, nope, but good guesses though.
My guesses are:
Purple Blocks - Ice Blocks that change Sonic's traction while he's on them.
Gold Blocks - Falling blocks, when Sonic steps on them, the platform would fall.
We have a winner !
In Picture 3, the blocks with the yellow tops do sink down and than fall, just like the floating platforms in GHZ. ( they also shatter into pieces when hitting the ground)
However the purple blocks guess is wrong.
But yeah I guess you could be right about the traction, however that's not a feature that has been implemented yet, and not pictured here.
Also keep in mind, we are only looking at the purple blocks with yellow front faces for remaining guesses.
Either they're pushable, or act a bit like springs by going a bit down first, then throwing you up really high like the ones in Metallic Madness. I'd go for the second, as they don't seem big or cubic enough to be pushable. or maybe they're just breakable, as the other ones break upon hitting the floor.
Is this kind of digressing brainstorming allowed as an answer for the quiz? :v:
Yes in picture 3, there are push blocks. (notice the ruts in the ground where the big yellow blocks are sitting, you can push the blocks around inside the ruts)
No chance of some new video(s) of your endeavors? For curiosity's sake.
Nope not yet lol
Well guys, small update here,
Took awhile but finally got a good prototype going for matching Fisheye to sprites in Unreal 4. Sure we had something going in UDK, but not with using 360 degrees worth of sprites rendered out to a single sheet containing 1024 individual sprites. The goal is to be able to match these against the Fisheye effect as close as possible,
Right now we can match only when moving the camera up and down or side to side, Moving the camera in and out also effects the Vertical up/down and horizontal Sides.
If you look below, you can see that the test sprite's sides match up with the sides of real blocks with firsheye applied.
Showing off more adaptive depth angels
Same with the tops
However when trying the mix the 2, Virtical and Horasontal, this is where things start to break visually (the issue only happens at the top or bottom diagonal side locations of the view, they work directly above or directly to the sides correctly when combining, i have a few hacky methods that i have attempted to get around this, but they don't work perfectl. Currently experamenting around with some other ideas, cause ehh i don't think doing it hacktacular is a good idea.
Wish i was a math master, because this next screenshot is just unacceptable ...…
Kinda Getting there,,, but its still off a bit....there's a bit of an odd rotation still present as the sprites get further away to the sides.
Still better than one of the old versions I left in the screen to the left.
P.S. oops I let it leak. remnants of some blocks that shatter when they fall to the ground. ( oh wait that's nothing new, was in UDK version XD XD XD)
Little glitch I noticed when flipping sprites.
Watch closely when sonic is facing towards the camera.
Many animations from X-treme are in most cases renders of only 180 degrees of a model, and well one would think that simply Mirroring the frames would produce the complete 360 degrees needed visually. But no! that's not the case.
Instead! You end up with , uhh, well with some pretty broken looking BS.
So, uhh, to fix this mess, I used a little math trickery to progress the running animation ( by Adding, yes talking about "+" here guys) 8 frames ahead where the leg swings back into position.
Lucky us, it lines up with the non flipped sprites leg position.
So with that figured out, I used a little magic, and made it so that when we flip sprite, than 8 frames progresses ahead automatically, and Boom!! We got ourselves a consistent rotation visually.
The Sprite Set:
Mirror than skip to 8th Frame
The magic Shader Material section only used for the mirroring and corrections:
The full sprite material spaghetti birdnest graph thingy! Just to give an idea of how much work went into something so simple:
Wait but its not even finished yet! OMG!
Why is it that what seem like simple problems require complex answers, especially in computers? Good work.
Good to see you still working hard on this, and thanks for the update!
The last 3 Days for AXSX has been rearranging the file structure. So pretty much, the last 3 days looked like nothing but this:
Reason for the re-structure is to make things a little more easy to navigate by cutting some extra folders that were required when porting UDK level layouts over to unreal 4.
Seems there are many more days for restructuring over 63,605 files, 25,378 Files of which are the 3D building blocks used for making the level layouts.
So far its taken 3 days just to do the 25,378 building blocks move alone.
Why does it take so long you ask? It seems, When you change files between folders inside Unreal 4, you have to manually start a File re-directory update so that other files like levels and or actors know where the assets have been moved to.
This is soooo slowwww! But hey its automated! I'm doing smaller 10,000 or so groups at a time just so that in case I get a power outage , i can recover from the previous move's end point from a backup rar. Must be carful , because if something happens, it could corrupt the whole process!!
Anyways just here to say we're not dead yet, Although,,,,,,,, this may just be what drives the nail in my lid... lol ( that's a joke)
I know that feeling... Not in the same sense, but still...
Just like people have been telling me about my attempts at writing Novels... Try not to give up until the very end.
It's good to see you guys are still working on this.
I'm just wondering, but isn't UE4 holding you back?
It seems like the transition to UE4 caused many problems.
Wouldn't it be easier to just use C++ and Open GL ?
I guess UE4 has many advantages, like collision detection and shaders, but since Sonic X-Treme is pretty "primitive", it shouldn't be hard at all to at least implement the 3d rendering part.
Plus PCs are so fast you don't even need to truly optimize the rendering part, you just throw everything at the z buffer and you will still hit 60 fps on crappy computers.
No need for advanced portal clipping, bsp trees and such.
I think it took me like 1 hour with no previous knowledge to have a basic map renderer on PC, including gouraud shading. Everything is so much easier than on the Saturn.
Is it because your programmers don't have enough time for it?
XD, I guess you could say its a little bit of everything, Sure Unreal 4 seems to be slowing the project down in some areas along with Programmer and also my own lack of time in other areas.
It's cool, we're pushing ahead slowly but surely 1 thing at a time.
Right now the biggest issue we are having is holding back the final part for sprite animation system: https://forums.unrealengine.com/unreal-engine/feedback-for-epic/1584791-need-new-rotation-axis-data-feedback-desperately
Everything for the animation system is done except for passing the rotations of the player pawn to the Sprites so that the sprite displays the correct sprite image which would align with Sonic's orientation.
The sprite system is complete and works as it should, However the rotational data feedback coming out of any object or even the player are jumping all over the place when you rotate it.
.... Its quite frustrating and It sucks eggs so hard. Because everyone I've turned to, can not come up with a solution to the issue, I've tried asking many reputable programmers, some from the sonic fangaming community, but many ppl are at a loss.
I've come very close to salving the issue on my own, But, It seems that every time I'm so close, something else breaks within the rotation data gathering/translation/correction system that I've been working on.
Right now my plan has been in separating each Axis to its own separate thing and locking out the other 2 Axis out so that the separated axis stays stationary when the other 2 axis rotate. I'm also using math to correct the numbers from jumping, caused by the interference from the other 2 Axis which filter into the separated axis.
Its hard to explain without giving a visual. (but yeah please refer to the link above for a better explanation of whats going on)
If anyone could salve the math, I'd be able to make it a paid job for sure, because this has been something we've been looking to get salved on and off for over a year now.
Just dropping by to say , We are on the right track for the Rotations data issue described above! Hell yeah !
Thanks to Josh and Meinukey.
Hello ! Just Showing off the new model that I have been working on for use in AXSX, I'm doing the heavy modeling, while Andrew is handling the quality control and minor tweaks here and there. The model was based on random Screenshots and videos of the original model used to render out the Sonic X-treme sprite sheets.
Here are some in game views next to the original sprite. (Please keep in mind that this is all very much still a WIP.
For example, The pictured in game shader is not final, the idea is that it's going to be tweaked to match the original glossy look and feel)
Also it's planned to add the pixelated shader to a model so it will bring more aesthetics to classic look
That looks so good and I can't stop giggling about it.
I've been following this project for a few years now. Even if the development has been slow, I still love seeing progress on it. You guys have done such an epic job with this and I hope to see this game get finished (even if it takes forever)
Also that Sonic model makes me moist that is all.
Separate names with a comma.