Jump to content

Josh

Developers
  • Posts

    23,103
  • Joined

  • Last visited

Blog Comments posted by Josh

  1. I found that compression on the server is a really bad idea because any file that is big enough to benefit from compression also needs to be uploaded in a compressed archive, either due to file size or number of files. The only files that really qualify for this are the library binaries and header files.

  2. Well, in Ultra C++ has entity components, so there is not such a need to merge C++ and Lua projects together. Also, since we can now load files from a URL the default templates do not have to contain all the files for examples to run, since they can just be loaded off of github with a URL.

    I wanted to see how this system would handle header files. These are a strange case because each one is very small, but there can be thousands of them. I tried testing with the Leadwerks header files. They're only 19 MB, but uploading 1700 individual files via FTP is not feasible. I waited 20 minutes and it's still calculating the job size, or something like that.

    I think I can make it so a zip file will get extracted automatically, so I can upload all headers in a single zip any time they change.

  3. However, the PHP Phar class does not preserve the original file modification time, and I can't find any way to do it. I can't even find anything mentioning the problem. It's pretty telling of the tech industry as a whole that all the discussion is about reading tar files and there's virtually nothing about writing them.

    So I created a little utility to change file times, and now the whole system works:

    #include <iostream>
    #include <string>
    #include <sys/utime.h>
    
    int main(int argc, const char* argv[])
    {
    	if (argc < 3) return -1;
    	std::string path = argv[1];
    	uint64_t timestamp = atoi(argv[2]);
    	struct _stat64 filestat;
    	if (_stat64(path.c_str(), &filestat) != 0) return 1;
    	__utimbuf64 utm;
    	utm.actime = filestat.st_atime;
    	utm.modtime = timestamp;
    	if (_utime64(path.c_str(), &utm) == 0) return 0;
    	return 2;
    }

     

  4. I switch from ZIP to tar.gz for the compressed downloaded data because ZIP files weren't storing the right timestamps. In PHP 8.0 you can set the time stamp inside a ZIP file, but this site won't currently work with PHP 8. Tar I guess is built around unix time stamps so it works much better.

    This is pretty nice because the application files themselves and your project file are all stored with the original time stamps.

    However, there is one potential problem. 

    • You create a project at 8 AM.
    • I upload an update at 9 AM.
    • You modify a file at 10 AM.
    • You download the update at 11 AM

    In the situation above, your project won't show as being out of date because your modifications at 10 AM (independent from time zone) came after the updated file was uploaded.

    Template updates aren't very common, and overall I think this is the simplest and best choice.

  5. Yes, I am allocating one 4x4 matrix in the material structure to store user parameters. These will be defined in the shader family, so you can set them with a string. They will be loaded from the material and used in the shader.

    For post-processing effects, I am doing something similar.

    Something like this:

    material->SetParameter("normalstrength", 2.0);

     

    • Like 1
    • Upvote 1
  6. I ended up using tar to extract files, which is now built into Windows. Some behavior tar has that annoyed me at first is that it retains the original time stamp of a file when it is extracted. In other words, if you extract a tar file, the extracted file will show whenever it was last modified, BEFORE it was compressed. I would normally expect this to show the date/time it was extracted from the tar.

    However, I found that if I retain the original time stamp when creating projects, we can more accurately test if a project template file is newer than the generated project's files. In Leadwerks, if you uninstalled the application and reinstalled it, all project templates would appear newer than the files in your projects, so any changes would be overwritten (with a backup copy of the file in the same folder).

    Now, if you use tar.gz files for your project backups, you can retain the time stamps and everything will stay in sync with the editor very nicely.

    • Like 2
  7. @Cromartie There was a very detailed discussion here about this:
    https://www.ultraengine.com/community/topic/60986-ultra-engine-pricing/

    Basically, Steam is no longer a viable marketplace for desktop software, and I have to adjust to that reality. If I were to release Ultra Engine with the same terms as Leadwerks, it would make a fair amount of sales the first month and then just completely stop. I would rather not release Ultra at all and keep it for my own projects than to release it like that.

    In the long run, the subscription model is the only thing that works. That's not as simple as just charging a monthly fee for the same thing you had before. A subscription product needs to have ongoing development with frequent releases and a long roadmap with no big U-turns. Remember L3DT? Unwrap3D? C4 Engine? They all used the buy-once model and they're all stagnant now. Even if you do paid updates every year, it still sucks because then you have year-long periods with no new features, since you have to postpone them all for the upgrade.

    • Like 2
  8. For installing files, I found what works really well is to download all files to a temp folder, generate a bat file that extracts everything into the "Program Files/Ultra Engine" folder (or wherever the destination is, and then run the .bat file with admin privelges with Shell execute. There's no need to create an application that has admin privileges. We can even have an option to open the folder the .bat file is in and do a manual install, so the user never has to agree to give the application admin rights, if they want, and they can inspect the bat file to see exactly what it does before running it.

    • Like 2
    • Thanks 1
  9. 53 minutes ago, Genebris said:

    I hope you don't ask for credit card inside the client. I don't trust any software besides Firefox.

    No, purchases only run on our site, and the server does not store CC info at all. PayPal issues a "token" that is associated with only this domain, and can't be used from any other site.

    • Like 2
    • Thanks 1
  10. I think this is interesting. It would probably be possible to display the full forum contents in the application, with a reply box that acted more like a chat system, like Discord but organized like a forum to facilitate in-depth discussion. It is possible to do the same thing with the marketplace / downloads system, which was my original plan, but I'm not going to pursue anything like that until the amount of content we have ready demands it.

    Anyways, I think that is as far as I will take these experiments for now. It is cool to see it working. But the real reason for all this is license management.

    • Like 4
  11. One big change in Ultra is I use a lot of branching logic (if statements). I've seen absolutely no downsides to this on modern GPUs, and it lowers the total number of shaders used, which in turn means most of the scene is drawn in one or two super batches.

×
×
  • Create New...