Wow!!! That's awesome!!! Thanks a lot!!! I'm going to be traveling the whole day, but will check it out tomorrow in detail!!! I have an internal version with many optimizations that is about 30% faster than the original and uses 2kb less of ROM. So, I am quite excited to see your optimizations!! I hope they are different and it can be even faster!! Also, with your 3KB less of RAM and my 2KB less of ROM, I am already thinking what else can I fit in the cartridge for an extended version! (and that "button to walk faster" suggestion might be one of them!)
I don't want to criticize you - I think what you have done is massively awesome and that you make your code public even more so!! but it is a pretty poor habit to keep developing a project that is on github in a private branch..don't worry and open up: push all your improvements to a development branch!...chances you two have done double work here...like I said, don't take this as a negative comment though, just a humble suggestion!!
right, totally agree. I did improvements on it because my initial idea was to reuse the engine for another game. So, I never intended to just update this one (it is currently living on a separate repo). I usually do not make my internal development code public until I finish the game, since about 80% of the games I start I never finish. So, I do not want to advertise anything until I know I can finish it It was this thread that made me think of updating the original game!
I usually do not make my internal development code public until I finish the game, since about 80% of the games I start I never finish
But if you publish one, you give a chance to someone else to finish it in case, didn't you?
There usually is time between when I make changes and when I push them to the public repository for me too. Usually I want to wrap up a related chunk of work first and do sufficient testing to make sure they’re working nice and good. Or maybe I’m not sure yet whether I want to do it (e.g. when there’s a trade-off involved).
I use history rewriting extensively (Mercurial Evolve) to make sure my changesets are cleanly separated and ordered before I push them live. Usually when I implement a feature in steps A, B then C, as I work on C I will notice there’s some more I want to add to A or want to introduce an intermediate change, or maybe there’s a bug in a previous change. Once I push them public there’s no way to modify them anymore and these changes would have to be separate fixes on top of them, while I prefer the original changes to be better so that there’s less noise on the repo.
So things can sit on my PC for a couple of days or weeks or months while they get molded into the batch of changesets that I want them to be. I don’t think there’s anything wrong with that, I prefer to take my time to share something clean with the world rather than a rapid sequence of messy changes just for the sake of getting it out ASAP.
As for when to publish projects, for me it’s based on when I announce it (enough confidence that it’s going to be a thing) and/or whether I want to discuss the code (link to it). But I can totally understand if others have different thresholds.
As for publishing dead projects after the fact (and hoping others may finish it), not a big fan of it unless there’s something noteworthy in the source code that’s worth sharing just for the purpose of discussion or demonstration .
That's the theory, but in practice that does not happen. Continuing some else's code is usually a difficult task...
(I published the unfinished World Rally sources five years ago and... there they lay, unmolested)
@santiontanon No much on TV today, so I pushed the speed up from 18,5% to 22%
Unfortunately I don't think that your boost up any my boost up in speed can be directly added up, but I still hope there are some differences that fit together.
Very nice!! I have actually started merging your version with mine. Not all the changes merged yet, but I'm getting there!! we are now up to about 39% faster than the original now So, at the default viewport size, the game has gone from 2.64 frames per second, to 3.67!! Pretty cool!!!
The current code I use to test is stripped out of the game, so, I need to set it up again into the game, and create a new repo (the new version uses slightly higher resolution textures, and the old graphics need to be updated ). Let's see if I get time to do it over the weekend. Will post the link to the new version once I upload it!
Thanks one more time for this!
That's the theory, but in practice that does not happen. Continuing some else's code is usually a difficult task...
(I published the unfinished World Rally sources five years ago and... there they lay, unmolested)
World Rally......it is a pity that no one has taken up the project again .. ;(
Btw, I just pushed the code of the new experimental version of Tales of Popolon to GitHub in case anyone is curious: https://github.com/santiontanon/talesofpopolon-ext
The main new feature is a much improved raycasting engine that merges lots of updates I had been doing for fun with the latest updates by NYYRIIKI. I have not yet been able to merge all his updates. But I'll do it bit by bit, as the new renderer is significantly different form the previous, and what I have to do is to understand the changes and see if they still apply to the new version :)
In any case, do not miss trying it on a turbo R, it runs so much faster than before on a turbo R now :)
Also, beware this version is unstable as I think I broke several things when updating the renderer, since I wasn't paying much attention to the game itself. But I'll be fixing those. Also, after all the optimizations, even with updated new higher-res graphics, there is now 2.5KB of free space in the 32KB rom (while the original had something like 15 bytes of free space haha). So, I have a long list of additional features I wanted to add to the original that were left out, and that I'll be adding bit by bit :)
This sounds great, so this will eventually become the Tales of Popolon Remastered Extendend Plus Deluxe version?