What are you working on? (Game Making Thread)
- Thread starter Ellie
- Start date
Huh. I found Tale of Three Witches on my hard drive. I never realised how far I got into it. The Kickstarter failed and I just kind of fizzled out. But hey this is pretty promising, I think. I might pick it up again.
I mean, OK, it does need work, but I made a point of it being only three weeks' work to demonstrate the amount of work I'd put in during the Kickstarter. So with some polishing I'll have something decent out soon. If I don't get bored again and start making an FFVII fangame.
I mean, OK, it does need work, but I made a point of it being only three weeks' work to demonstrate the amount of work I'd put in during the Kickstarter. So with some polishing I'll have something decent out soon. If I don't get bored again and start making an FFVII fangame.
I managed to finally get file transmission working over the live game info socket. Just getting that to work has taken longer than making the rest of the project combined.
Now when someone enters the map, a placeholder sprite is shown until their file is received over the socket. Kinda like that pop in you see in MMOs.
This also means that you can edit your graphic on your local computer whenever you want, and the changes will be visible to others as soon as you relog.
Now when someone enters the map, a placeholder sprite is shown until their file is received over the socket. Kinda like that pop in you see in MMOs.
This also means that you can edit your graphic on your local computer whenever you want, and the changes will be visible to others as soon as you relog.
I managed to patch RPG::Cache to do a bunch of checks and get it to use Yeyinde's RGSSAD decrypter to emulate browsing through the archive for resources, because I can't redirect RMXP's inbuilt functions to use an alternate archive.
I also finished an in-game upload system, but I don't know how fast it is because I had to screw around with my TCPSocket and do some pretty weird shit to get it to work.
It's not long now - I just have to add some little features (make favourites & history) and send the server to my friend with fiber internet, and everything is ready to go. I could probably skip the fiber part for the first release actually, it would be just super slow.
:D
I also finished an in-game upload system, but I don't know how fast it is because I had to screw around with my TCPSocket and do some pretty weird shit to get it to work.
It's not long now - I just have to add some little features (make favourites & history) and send the server to my friend with fiber internet, and everything is ready to go. I could probably skip the fiber part for the first release actually, it would be just super slow.
:D
coyotecraft
Sponsor
Researching. Planning.
I really hate starting something that I know I won't be able to finish. Hate it. hate it. hate it.
I really hate starting something that I know I won't be able to finish. Hate it. hate it. hate it.
Spent most of today thinking about how to deal with render-passes against cameras.
Decided to make render passes a single call with cameras being an optional state to activate;
The plan also makes deferred rendering super easy to deal-with;
Still need to figure out how to handle the GPU ROP switches (that shadow pass is exactly why this needs careful thinking about).
I also don't like preparing the same view twice in one loop, in the end I'll probably move the weight of the camera preparation to the xiSceneManager::Run() method as that is heavily threaded so can deal with the extra load, avoiding repeating the same heavy work twice during the rendering stage (single-threaded).
EDIT: Personal reminder -Move camera occlusion to job thread system and make xiSceneManager::Wait() help out the job manager with completing tasks (Can cause thread to spin uselessly).
Decided to make render passes a single call with cameras being an optional state to activate;
C++:
sceneManager->Run();
uiManager->Run();
if ( sceneManager->PrepareView( camera ) ) {
sceneManager->RenderPass( solidPass );
sceneManager->RenderPass( alphaPass );
sceneManager->CompleteView();
}
uiManager->RenderPass( solidPass );
uiManager->RenderPass( alphaPass );The plan also makes deferred rendering super easy to deal-with;
C++:
if ( graphicsDriver->PrepareTarget( deferredTarget ) ) {
if ( sceneManager->PrepareView( shadowCamera ) ) {
sceneManager->RenderPass( shadowPass );
sceneManager->CompleteView();
}
if ( sceneManager->PrepareView( camera ) ) {
sceneManager->RenderPass( deferredPass );
sceneManager->CompleteView();
}
graphicsDriver->CompleteTarget( deferredTarget );
}
sceneManager->RenderPass( compositionPass );
if ( sceneManager->PrepareView( camera ) ) {
sceneManager->RenderPass( alphaPass );
sceneManager->CompleteView();
}Still need to figure out how to handle the GPU ROP switches (that shadow pass is exactly why this needs careful thinking about).
I also don't like preparing the same view twice in one loop, in the end I'll probably move the weight of the camera preparation to the xiSceneManager::Run() method as that is heavily threaded so can deal with the extra load, avoiding repeating the same heavy work twice during the rendering stage (single-threaded).
EDIT: Personal reminder -
I am working on many things, one of them being a complete reimplementation of the RPG Maker player, from scratch.
I intend to open the source on it, just clarifying some permissions before I do so.
Have a look-see! (multi-image spoiler)
Edit: In case this is unclear, this is not running in Game.exe, or using any RGSS dll.
Don't laugh at my test map.
Obviously not perfect (the current windowskin implementation is atrocious - just hasn't made it to the top of the list yet).
But replicating vanilla with close to pixel-perfect accuracy, while using a fully OpenGL accelerated renderer, has proven to be an unimagineable headache. *cough*i hate font rendering*cough*
Before anyone asks - this is running whatever scripts the game is using - it should be "highly" compatible with most RPG Maker scripts (given a project of the appropriate RM version), but I would not expect compatibility to be absolute. Things that directly modify or call against the RGSS dll will obviously fail - because this engine has no knowledge of it. But yeah - this is not an "RM-like" engine, it's actually running an RM project, complete with scripts. It's written in C#, using IronRuby. Before you go "booooo", let me add that I've manually added Win32API and Fiber.
Mono support inbound, which will enable other platforms besides Windows.
**drops the mic**
UPDATE: Preview release here!
I intend to open the source on it, just clarifying some permissions before I do so.
Have a look-see! (multi-image spoiler)
Edit: In case this is unclear, this is not running in Game.exe, or using any RGSS dll.
Don't laugh at my test map.
Obviously not perfect (the current windowskin implementation is atrocious - just hasn't made it to the top of the list yet).
But replicating vanilla with close to pixel-perfect accuracy, while using a fully OpenGL accelerated renderer, has proven to be an unimagineable headache. *cough*i hate font rendering*cough*
Before anyone asks - this is running whatever scripts the game is using - it should be "highly" compatible with most RPG Maker scripts (given a project of the appropriate RM version), but I would not expect compatibility to be absolute. Things that directly modify or call against the RGSS dll will obviously fail - because this engine has no knowledge of it. But yeah - this is not an "RM-like" engine, it's actually running an RM project, complete with scripts. It's written in C#, using IronRuby. Before you go "booooo", let me add that I've manually added Win32API and Fiber.
Mono support inbound, which will enable other platforms besides Windows.
**drops the mic**
UPDATE: Preview release here!
Sharing is fun! Let me do it again.
One of my other projects is experimenting with voxel-based LoD, trying to render as many billions of point-cloud data elements as I possibly can.
This screenshot looks boring, I'm aware - the cubes are, in fact wrapped and textured, you just can't tell because I haven't made actual textures yet.
Moreover, I'm working towards rendering them efficiently enough for VR. (I recently got an Oculus Rift and have been itching to make something for it myself. Clearly, I'm the dive in headfirst, learn to swim later type.)
What's not apparent from the screenshot is that its a lot more "blocks" than it looks like. My current LoD methods sadly are detrimental to depth perception, as I half-res them beyond a certain range. I will find a more graceful solution, or at least a way to mask the illusory depth issues. Fun fact though - the terrain is generated in an interlaced pattern; first the heightmap, then the halfres, then the missing data. Meaning that moving around is less laggy than, say, Minecraft, by comparison, despite processing roughly 80 times as many blocks at any given moment.
Long technical rant on the topic:
One of my other projects is experimenting with voxel-based LoD, trying to render as many billions of point-cloud data elements as I possibly can.
This screenshot looks boring, I'm aware - the cubes are, in fact wrapped and textured, you just can't tell because I haven't made actual textures yet.
What's not apparent from the screenshot is that its a lot more "blocks" than it looks like. My current LoD methods sadly are detrimental to depth perception, as I half-res them beyond a certain range. I will find a more graceful solution, or at least a way to mask the illusory depth issues. Fun fact though - the terrain is generated in an interlaced pattern; first the heightmap, then the halfres, then the missing data. Meaning that moving around is less laggy than, say, Minecraft, by comparison, despite processing roughly 80 times as many blocks at any given moment.
Long technical rant on the topic:
Fun experiment. I've learned a lot about data management. The current phase of these experiments is trying to create a 3d, realtime run-length "chunk" model. That is, not just encoding and decoding data - but storing the entire chunk as a sparse list of cubes that have height, width, and depth, in voxel units. Fact is, in any voxel game I've seen, this would garner a performance profit due to the sparseness of data. It would be possible to create conditions where this is less performant than flat arrays, but those conditions would be rare. Not to mention, storing the point cloud data in such a manner means I can pass it to the renderer as-is, and it's ready to go - no costly optimizations (other than basic culling checks, which are now less expensive) would be neccessary.
What I have learned, with confidence, is that noone has pushed this boundary even close to its limits yet. I'm not the only one trying, but I've opened the door enough to realize there is far, far more to be done in the field of voxel/particle rendering as it applies to games.
I got the initial idea from an old Bethsoft interview related to Skyrim. They were talking about rendering the mountains in the distance, and it really is a lovely effect. I've always been sad that games like, say, Minecraft, can't do the same. Which made me question "...why can't they?" The tricks that have been employed for polygon terrain for years are being applied to pixels, why can't the same logic be applied to voxels? Well, the simple answer is that a voxel game needs to be lossless. Or at least, that's an assumption I see a lot of people making. But it really doesn't. The lossless data needs to exist somewhere- but lossless does not mean uncompressed, nor does the entire visible world need access to its lossless data 100% of the time. So I started looking at image compression, a field that has come so far and had so much coverage. But specifically, I started looking at its roots. The dawn of the internet, when images were too much data to send over a dialup connection. Voxel worlds are facing the exact same challenges - which we have already beaten in two dimensions.
I love voxels. If I were approached back in the late 80s and asked how to make a 3d video game - I most certainly would not have come up with polygons- I would have tried to make the pixels themselves 3d. I like to imagine that reality - as the years went on, and screen resolutions, in 3d mind you, got higher and higher, I think we would have a very different gaming world from the one we have today. Objects would have mass, they would have insides. VR would be simpler in some respects, as we'd be used to volumetric materials.
So I try to bring that imaginary reality into this one.
What I have learned, with confidence, is that noone has pushed this boundary even close to its limits yet. I'm not the only one trying, but I've opened the door enough to realize there is far, far more to be done in the field of voxel/particle rendering as it applies to games.
I got the initial idea from an old Bethsoft interview related to Skyrim. They were talking about rendering the mountains in the distance, and it really is a lovely effect. I've always been sad that games like, say, Minecraft, can't do the same. Which made me question "...why can't they?" The tricks that have been employed for polygon terrain for years are being applied to pixels, why can't the same logic be applied to voxels? Well, the simple answer is that a voxel game needs to be lossless. Or at least, that's an assumption I see a lot of people making. But it really doesn't. The lossless data needs to exist somewhere- but lossless does not mean uncompressed, nor does the entire visible world need access to its lossless data 100% of the time. So I started looking at image compression, a field that has come so far and had so much coverage. But specifically, I started looking at its roots. The dawn of the internet, when images were too much data to send over a dialup connection. Voxel worlds are facing the exact same challenges - which we have already beaten in two dimensions.
I love voxels. If I were approached back in the late 80s and asked how to make a 3d video game - I most certainly would not have come up with polygons- I would have tried to make the pixels themselves 3d. I like to imagine that reality - as the years went on, and screen resolutions, in 3d mind you, got higher and higher, I think we would have a very different gaming world from the one we have today. Objects would have mass, they would have insides. VR would be simpler in some respects, as we'd be used to volumetric materials.
So I try to bring that imaginary reality into this one.
coyotecraft
Sponsor
Lag Hunting.
The biggest one I've found so far is the battle system running a scroll_screen method with every frame update. It's part of a zoom function but we're not using it, and even if we did the screen wouldn't be scrolling the entire time. That fixed 99% of the lag.
Still a short delay when receiving damage or possibly an issue with the hit counter.
The biggest one I've found so far is the battle system running a scroll_screen method with every frame update. It's part of a zoom function but we're not using it, and even if we did the screen wouldn't be scrolling the entire time. That fixed 99% of the lag.
Still a short delay when receiving damage or possibly an issue with the hit counter.
"Lag Hunting" - Proceeds to discuss frame-rate problems and not latency problems :/
Work related stuff; one massive bug that's been hanging around since day 1 has been squashed. Source of it was an Apple function on iOS giving undesired results for the actual way it is used (Projecting into windowing co-ordinates, rather than camera co-ordinates, then sorting as if it were camera co-ordinates).
Said function was also really dumb, apparently Apple won't let you send a const windowing view port, despite the function not modifying it. This is why const-correctness is important! If this was part of a const pointer reference then it would be entirely useless and an extra stack variable would be needed just to avoid it, or the value would have to be mutable (if in Obj-C++).
Going to take a break. Stress levels through the roof.
May even go back to writing the Ruby console interface I'm making for the new projection.
Work related stuff; one massive bug that's been hanging around since day 1 has been squashed. Source of it was an Apple function on iOS giving undesired results for the actual way it is used (Projecting into windowing co-ordinates, rather than camera co-ordinates, then sorting as if it were camera co-ordinates).
Said function was also really dumb, apparently Apple won't let you send a const windowing view port, despite the function not modifying it. This is why const-correctness is important! If this was part of a const pointer reference then it would be entirely useless and an extra stack variable would be needed just to avoid it, or the value would have to be mutable (if in Obj-C++).
Going to take a break. Stress levels through the roof.
May even go back to writing the Ruby console interface I'm making for the new projection.
Lazerus....
Need help figuring out how to make a ripple effect...
or possibly a script function to generate an image at random intervals on the x axis at the bottom of the screen travelling upward.
I can do it in events, but I need to break into scripts...Have to get into it!
Need help figuring out how to make a ripple effect...
or possibly a script function to generate an image at random intervals on the x axis at the bottom of the screen travelling upward.
I can do it in events, but I need to break into scripts...Have to get into it!