I’ll definitely try it. Making a full-blown project though may be too much work but I don’t know what to do with my free time so it’s a possibility.
the main reason i dont use our current client is because i have to run the broken editor via wine on linux, and this makes the my scripts have a %50 chance of being erased from the text box after every button click. so im just waiting for you to release the update.
I’ve often just become very frustrated with the state of the tools and having to work around limited and/or broken functionality, were there a tool that enabled me to develop content and not have to submit it to a greedy french man for his own profit, I’d be all for getting back to development. It’s really the only reason I work on my engine (which now requires a major networking revamp to be considered a viable tool…), it’s just all about who gets there first and does it properly, meaning I’d most likely use your tool for something serious. I miss not developing phoenix :C
You mean you do miss developing Phoenix :[[[[
Feeling like the project is going to be useful is a big part of what drives me to continue, so it’s nice to see that it seems wanted. I guess that’s the best that can really be hoped for at the moment.
I finally got a little tired of WoW and ran a quick test that confirms my suspicion about a single, large file dramatically improving performance on random loads. The load time of 1218 levels was virtually identical (with the difference being completely insignificant) on a fresh start of Windows compared to after the file had been first loaded. This would solve the problem that was being faced with some lagging on the first use of levels after starting Windows. (Or after the files had been removed from OS cache, which is the real concern.) I’m not sure if a multi-level combined format would be a good idea, or some sort of auto-archiving should occur by the server.
All of this is really extreme nitpicking anyway. In normal use cases, this loading lag isn’t even going to be experienced, as it’s only visible when traversing levels at absurd speeds. Even with something like the typical “staff boots”, is a tiny occasional stutter that big of an issue to worry about right now? lol
What I want from your project right now is for it to be at a point where I can program stuff with it.
So no, I don’t care. Unless it’s a core thing that will not be possible to change/upgrade later but it doesn’t seem like it. The single large level idea doesn’t appeal to me unless having it could solve the problem of “chasing an NPC through levels” like tricxta calls it.
I’ve not really spent a whole lot of time working on this lately, as I’m sure has been obvious. I managed to get the level navigation stuff to where I was satisfied enough to move on. So… I implemented the equivalent of showimg, though it’s very basic at the moment. Out of curiosity, I plopped 5000 alpha-blended 50x50 images onto the area to see how it would impact the frame rate. Initially it was terrible, around 50 FPS, because I hadn’t really done much with that part of the rendering code in a while. After some optimizations, it’s up to what you see below. This is amusing when Graal would lag with just a few alpha-blended images sometimes. (“Lights”) There’s still some room for optimizations here too, I believe. But I’m not worried about it for now.
I may skip over adding the other functionality to the image renderer for now and start working on something for animations.
[ATTACH=JSON]{“data-align”:“none”,“data-size”:“full”,“data-attachmentid”:189537}[/ATTACH]
Yes! Now we can photoshop our levels from within the game itself!
I wonder if we can get particle emitters going on this badboy
ya that’s good
that’s how i want to play graal
Sorry, I’ll try to show you something you can comprehend next time.
Here are some ganis converted (via code) to the new format and rendered. The one on the left is classic_gc_tree. It has some small issues still. I haven’t looked into the cause yet. This took forever because I had to figure out how to do transparency for the paletted PNG files Graal uses. I ended up writing one method after struggling with it for a few hours, then realizing there was a very simple alternative afterward… annoying.
Rendering these didn’t even noticeably touch the frame rate. What you see in the video is lower because of the recording.
I’ll be fixing remaining issues (like the tree animation) and testing more Graal ganis over the next few days to ensure everything is working properly. You’ll be happy to know that these animations will be as flexible as everything else. You define the contents entirely, so there are no “defaults” or copying of your character’s attributes. (There won’t even strictly be a character… that’s entirely implemented by the server developer if they choose.)
Edit: It turns out the tree animation isn’t quite broken. The person who made the gani used a size larger than the emoticon images for the sprite definition. This causes the texture to repeat in the extra space.
[video=youtube_share;tj4W04Xfej8]https://www.youtube.com/watch?v=tj4W04Xfej8[/video]
Nice, after animations, what’s left client feature wise? I’m curious as to how long it might be until we can start developing offline content.
There’s still a lot to do. A lot of what’s been completed so far has been a feature-incomplete version of what ultimately needs to be done. So pretty much everything has to be revisited and enhanced. The biggest thing that needs attention is the script engine and its integration with all the new features. It also needs all of the built-in functions/data added to it.
I wouldn’t expect to make anything available for quite some time still. Months for sure. Warm weather is also coming, which will mean less work being done.
I spent what little free time I had today getting libmng set up and figuring out how to use it to extract the data I need to display MNG images efficiently. After multiple times of thinking it wasn’t even going to be possible to do it the way I wanted, I found a solution. I’ll get that finished up this weekend and play around with ganis some more. I’m also hoping to start on getting the script engine more integrated the way it needs to be this weekend. Then I could show an example of it being used to control movement of an animation… and… well, that’s Graal… at least in a basic form.
Fun fact: Graal’s MNG files are fucked. Trying to load any of the files that are renderable in Graal causes libmng to error with an invalid format message. gif2mng obviously doesn’t follow the MNG standard.
Edit: Oh, and MNG support is done now, barring any random issues that pop up as it’s used. Every frame is loaded into memory upon loading the image, which is kind of scary. If that turns out to be a resource problem later, it can be changed to actively render frames (thus only storing one frame in memory at a time), but that’s going to be much slower.
Loading all frames into memory wouldn’t be that terrible memory wise, or so I would have thought? What is the minimum amount of RAM you’re aiming to support for the client to run smoothly?
Currently we’re talking 4 bytes per pixel. So let’s say you’ve got a 100x100 pixel MNG with 100 frames. That’s 3.9 MB for one image, which doesn’t sound bad, but it adds up quickly, especially with larger images. I’m not sure if Direct3D in-memory texture compression might be an option later, but it would help, at a performance cost, I’m sure.
I don’t really have any overall goal in mind regarding maximum memory usage. I think that’s difficult to gauge this early on.
Why am I not surprised? I suppose we could always extract MNG -> GIF and work with that, couldn’t we?
You have to have an editor that can load Graal’s corruption first. The one I use can, but it’s old. (Jasc Animation Shop) But if you have an editor that can load them, just save with that editor after fixing the frame delays (Graal sets them to millisecond * 50.) and it’ll work normally.
Some issues with animations have been fixed and they seem pretty stable now. This leads to the part I’ve not been looking forward to. It’s time to start defining the engine scripting API. This is basically writing the equivalent of commands.rtf by deciding on what to name variables/functions/objects, what features are needed, and how to organize everything in general. This is really only annoying because any changes later on will break scripts anyone has written. It needs to be as perfect as possible from the beginning.