This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - djdduty
21
« on: May 05, 2016, 01:31:31 AM »
I've started a code repository so that anyone can use my source code to write their own programs to interface with the Turok formats if they wish. The repository is https://github.com/mdecicco/T4Loader and I also put a link in the original post.
Currently it's pretty limited since I started writing it all over again, but give me about a week and it'll be able to open/save all actor data and all level data. Once I'm done with that I'm going to do a quick rewrite of the actual editor I've been working on using the new code I'm writing now. It might be kind of buggy at first but I want to get something out as fast as possible that you can all use and experiment with.
There is something that I need some help with though. I've learned that there are about a thousand different types of variables that can be modified in the actor files... I do not expect to learn how to use all of these but I plan on making a hierarchical data editor that will allow us to modify any actor variable and any other data in the files, even if we don't know what it is. Using this we can mess with one thing at a time to see how it affects the game. Then maybe we can make a new thread and post our findings so that I can make the editor use the data better.
Expect contributions form me, I've recently learned a lot about reverse engineering byte data! What do you think about using the QT library for the editor? It's cross platform and has all the widget features the editor would need? Currently I'm spending my free time trying to get the new version of the software started but then I'll have some free time, hopefully.
22
« on: April 27, 2016, 07:46:37 PM »
Sounds great and its good to know this project is still in mind here, glad to hear from you again guys. I'm still interested in this no matter how long it takes. It really hasn't been that long though so just keep it up 
I might try to talk stinkee into making the Turok file serialization code into a separate library for use instead, so that other projects can be done using the Turok assets, and also so that the code will be a bit cleaner. That would also make it independent from any library, like silk currently, so that it's easier to share and also easier to use by other programmers if there are any here who want to make use of the files.
23
« on: April 25, 2016, 11:02:42 PM »
Hello everyone, I am alive. For a while after my last update I was kind of worn out from programming too much. Then I got a job so I've been kind of busy during the week. I'm sorry for not posting in so long. I'm glad to see that there has been developments in other areas. The future of T:E mods looks positive.
I plan to continue work on my editor, though I'll be a bit slower than I was previously. I'm going to create a github repository or two for my code so that other people here can use it.
Before I address the bugs that I left off with I want to write a more straightforward and intuitive interface for loading/editing the Turok formats so that other people here can easily use it for whatever they want to do. I want to create a separate library and repository for this.
Maybe try porting the graphics rendering away from silk, there seems to be a good amount of performance issues in that engine. I would say use Bearclaw2 but I haven't open sourced that... It should be simple to make a renderer for that though, there's nothing special going on really. Edit: Silk isn't open source either, no licenses setup, so you can't share that yet anyway, My bad. If you would like me to open source it so that you can share the editor let me know, you did most of the work in silk anyway.
24
« on: October 08, 2015, 02:03:24 PM »
I am still really unhappy with the frame rate, I constantly pester Stinkee about it. so you guys probably won't see much from me in the way of visual improvements, I'll be busy investigating and possibly re-doing our back end rendering for a while until I'm satisfied that there isn't some core problem eating up frame time.
25
« on: October 02, 2015, 12:50:40 PM »
... I personally like the idea of keeping it original because ...
That's the idea, we are really just playing around with some modern rendering techniques to see what it looks like and add the features to our renderer, but the plan is to keep the original look. Currently Stinkee is investigating their lighting model to accurately re-produce their lighting and all the original shaders so that it looks more accurate. I am continuing to investigate performance of everything to see if I can make it even faster for everyone, but don't worry the basis for saving more advanced changes and the user interface is also in the works.
26
« on: October 02, 2015, 11:23:26 AM »
I like the effects added to it, just looks better I think you should do both versions if possible. But either way the frame rates are much better with the effects. So overall I think that should be the deciding factor. But you know maybe some people want it how it was, me personally I would prefer it to be with the post processing, effects, and fast frame rates. This just made my day
The added post processing effects actually slow the program down considerably, or we would have them enabled by default. The frame rate increase is due to the fact that before we were rendering every object in the scene all the time, and now we only render what's on screen. This feature will be enabled all the time no matter what as it doesn't change anything visually and it provides large performance gains. The post processes aren't optimized, so they bring the frame rate down all the way to 40 frames a second or so on my computer(down from 400fps), but if there is interest we can work on optimizing them.
27
« on: October 02, 2015, 12:43:55 AM »
So do to some *cough* unfortunate circumstances *cough* the culling and speed improvement that we mentioned was accidentally not working in the build at the moment, but this gives me a chance to show you guys what we mean by speed improvements through some screenshots! Below is a side by side comparison of the render data before and after the culling takes affect, hz is just a fancy way for programmers to try and sound smart when they really mean fps. The millisecond calculation doesn't line up because that's going by the current frame, whereas the frame rate is the average frames per second over time.  Also, UI! (Coming soon)
28
« on: October 01, 2015, 09:11:20 PM »
29
« on: September 23, 2015, 04:15:04 PM »
Progress update time, time is flying. It's been a bit slow, Stinkee and I are still re-working a lot of things in the renderer. Again, it is mostly features that won't affect very much in the turok viewer since it all has to do with better rendering quality such as post processing and deferred shading. However, I feel it is necessary to get the renderer interface really nailed down before we start a big project with it and have to refactor code as we go. T4Viewer will already need some maintenance to get it running correctly again with all the changes we made but hopefully we can bring you guys another build soon as promised ( before I so rudely suggested on waiting until UI was done... my fault on that  ).
30
« on: September 14, 2015, 03:11:45 AM »
Okay, quick update for you guys since it's now the end of the weekend.
Currently Stinkee and I are working on Silk (The rendering engine), and as that is the core of the viewer / editor it means direct improvements there as well. We are adding some much needed features and performance fixes. When a new build is posted an actual changelog will be made, but for now I'll tell you what we are working on, just to keep you in the loop. Throughout the week we finished up object Culling to cut down on the number of draw calls each frame and thus increase performance, it's not the most streamlined culling at the moment but it's much better than before. This weekend I started on re-doing the little UI code we had to make it in to something usable, I got a little carried away with it but we are back to a nice code interface, so UI stuff should be up and running quickly. Also we relocated some input management code so that we can more easily use that in the future. At this very moment Stinkee is finishing up a new feature, that is the post processing steps. This means that we can now add things like FXAA and other neat post processes, but might not affect T4Viewer so much beyond that.
Stinkee still has a long way to go on figuring out the various file formats, so exporting files might be a little while off. The next big improvements you guys should see are ui, importing files directly into the viewer rather than having to use command line arguments and weird file placement, and visual changes. Soon we will try to emulate the Turok lighting and make some more performance improvements as well. We're also going to move the Viewer into it's own repository that anyone is free to view and contribute to if you want, but we're waiting until we stop overhauling silk all the time as it would be a pain to have to constantly update the library binaries.
Anyway, sorry for the slow-ish weekend, time really does fly some times!
|
Show Posts
