Jump to content


The Indie Stone
  • Posts

  • Joined

About EnigmaGrey

  • Birthday 05/27/1988

Profile Information

  • Gender

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Gotta disagree about most of this. Mods more often fill niches we're not interested in exploring, in ways that we feel would not be fitting with the game; Mods often scratch that power-fantasy itch that some expect from their games; mods often turn something more organic ( and yes, playing it safe is the natural outcome of that in this setting ) into something more gamey if that's what players want. This may sound judgmental, but it's all good to me -- the whole point of supporting mods is to let you do your own thing (up until it impinges development) while we do ours, after all. It's just that people as a group also do not agree on everything and don't seem to have a grasp on what they actually like. They often ruin the fun for themselves because of this. We can't make millions happy - sometimes we can't even make ourselves happy because working in a team is always going to be some of compromise, even while pursuing a specific vision. PZ can't be all things to all people short of recreating the universe atom by atom: you see needless grind, other people see 400 hours of gameplay inexplicably chasing those skills (when they could just change the XP modifier). I'm personally bewildered by this and we'll likely change the skill system to what we feel are it main detractors, but you do you. Same thing for combat. Some people do not seem to want to put in the time to plan ahead (anticipate momentum, know when they pushed too far for the underlying mechanics) or learn how it works (trial and error; change behaviour; die a lot) -- so be it, there's a mod for that. Some people do not like randomness in games at all -- so be it, someone will probably mod it out one day. But ... we're not going to take on things we feel would hurt the game or slow/distract development just because server owners are way too liberal with mod selection. :/ We respect your right choose, to customize the game. Just remember that our goals might not match your taste (same for individual servers). In practical terms? just got to get out of your own head and have some fun. That's all that matters (so long as you're not hurting other people). Don't worry about ruining the vanilla experience for yourself. Mod it, tweak it, or don't touch anything and embrace the suck. Don't overthink it, unless that's fun in itself, ofc. :p
  2. IsoThumpables are objects that can be thumped; it's inherited by IsoObjects which may be things like IsoDoor -- but every IsoDoor is ultimately an IsoThumpable. It's not that convoluted. You're looking at byte flags for loading isoThumpables from a save file. *Shrugs* I don't see how replacing a couple if statements with a full on trait system would make a difference in loading files that are so tiny. It's premature to blame your problems on load speed, frankly. OOP is often needlessly complex/verbose to the point it's difficult to conceptualize and expand upon. It's increasingly fallen out of favour for game development, giving way to entity-component systems. It's really what we should have done back in the day. Regardless, there'll be a lot of jank that developed out of necessity or while transitioning from C# to Java from back in the day. Welcome to the infinitely interleaving alpha-beta-release-maintenance cycle that is Agile.
  3. Yes, distance is a factor. But remember that 3D game engines have been built to handle this via decreases in detail or even basic fog to optimize it. We don't benefit from any of that/have to roll our own stuff because the game is 2D and isometric. Everything is drawn to a larger-than-the-screen texture (twice the size to facilitate zoom but this amounts to like .. a 5 tile border). That's how things like holding ctrl and dragging the mouse to the side of the screen work. This is also why 4K is such a boondoggle because now you're working with an 8-12K texture instead of "4k." That's a lot of pixels to push for any GPU on top of waiting for a theoretical 50 x 50 x 8 tiles and everything else on the pile (overlays, fov, lighting, objects, moving objects .etc) to be sorted. This shouldn't matter in b42. You can optimize this to a limited extent to gain a bit of performance (maybe draw the tiles in a circle so that there's 1/16-1/8th as many) but it's not really worth it. (Or you reduce the size of that texture and just let people deal with the black borders if they move too quickly or zoom out. That's a no-go.) In AoE, buildings were simple 2D sprites, weren't they (a composite of a base image and a depth image to fake 3D effects?)? I can't imagine it was costly at all (especially given the lack of variety). Older games tend to use tricks like this or baking everything into the ground plane (like C&C, Baldur's Gate), whereas we have separate Z levels (think the early 90s X-COM. In fact, X-Com Apocalypse is probably a good analog for the challenges that PZ faces in its current, public form). Most 2D isometric games don't do this even today. Rhino: If you have the option to use JDK 17 or above and can use the ZGC pauseless garbage collector then I'd do it. But if Rhino requires reflection to facilitate scripting, you're going to have a similar bad time to us with Khalua2. You need to avoid small allocations in Java to avoid it bogging down. Things like foreach can have unexpected costs. Profile constantly. I don't see the point in dick measuring languages -- you can bog down anything or blow your foot off. Use a third party lib for datetime if it affects you (Apache always has good libs)? I mean, my heart belongs to straight C89, but all that matters is you get your work done with what you have. Graphical rendering isn't really done in Java. LWJGL provides bindings for GLFW which provides a wrapper for various DLLs on the system of your choice, such as OpenGL.DLL or Wing.dll. It's no big deal beyond the theoretical overhead of JNI. C++ has the same problem with third party libs being crud. That's just universal to C and C++. Honestly it's why I rarely use either anymore. People tend to resist writing self-documenting code and the preprocoessor + pointers seem to really encourage this, imo. Not a bad thing, but it means you can start a project with a really nice library, hit a wall, go check the source and just have a complete "wtf" moment. With languages like Java or C#, it's usually clearer what the intent was. We'd spend years jamming PZ into an engine that was never built to handle something like PZ. It's custom or bust, really. The only change i"d personally like here is using a proper C build of Lua instead of a Java implementation, as "it'd at least help" with performance. Note that Khalua2 requires reflection, which means an utter crap ton of trash, which means bogging down the rest of the game for the sake of mods / GUI. It's a fair trade, but it's just another hole to fill. (Note this is why we have FPS settings for the GUI in options and cap it at 30 FPS -- or every second frame). I'm not going to touch on duplicating the game, sorry. I'm not comfortable with that.
  4. Sorting in terms of occlusion; the frustum of s 3D fps/3rd person over shoulder will contain far fewer things than an overhead camera giving 360 degrees of vision. AoE capped max units for the entire map. It was a very small number compared to PZ; we'd exceed the cap pretty much immediately on spawn if we were to do that. Red Alert 2 letting its fps chug if too many units were present wasn't a great approach. I just don't get the point of this -- yeah, its cool (I lived through it :p), but we can't roll back the clock and write the game like it's 1999 anymore (though the first versions probably count as they could be run on hardware from 2001 or so. It wasn't until 2018 that PZ required shaders. If Intel GMAs weren't so common, we probably would've advanced a lot faster -- but it couldn't handle the drawing the 3D models with em). Similar thing for Jedi: Academy, but we made a very generalized game spanning 3 platforms simultaneously in Java, not one custom built and optimized for specific hardware, as it's ports likely were. Rewriting the game in C and assembler isn't an option for us. Neither is greatly scaling it down, unfortunately. Iirc, caching is already done for PZ's pathfinding, as is reducing individual zombies into large hordes when unloaded to reduce costs. Modified A* to handle the possibility of 4 walls on a single tile? But again, not my job to know the intricate details of it. Same deal for whatever rendering algorithm is used. You're always welcome to poke around with IntelliJ IDEA's decompiler if you want. It'll probably provide clearer answers.
  5. This is because these objects are composed of multiple tiles and each tile has different lighting. It's not a bug; unsightly, yes, but just an intentional part of the way the game is built. It may change in the future.
  6. A city has tens of thousands of tiles instead of hundreds; thousands of isoobjects (like interior decoration and objects) and up to eight layers to sort through. Trees and grass on one level are much simpler. Think of it like unpacking a Pickup. You have 36 boxes. The only thing you can change is how fast you move them, not how many you move at each time. (The forest.) Now you try to unload a box truck. You have 180 boxes to move. Now imagine that box truck might be 8 trucks high and has half a dozen boxes nested inside each box that need to be sorted first. (A city.) What's going to happen? The job's the same -- move a box. But it takes much longer to complete because there's so many. You can only move them one at a time -- faster when fitter, but still only one at a time. Lot of programming boils down to this sort of thing -- how long it takes to interact with and sort a group of things; and unfortunately you do eventually hit a wall where you just can't go faster without significant consequences (if at all). ( That's also why having an arbitrary goal like using "100%" of your gpu or cpu is meaningless in practice, because sometimes things can only happen one way to get your end result.) (also you have to do it in reverse because the game is 2d and isometric, hence issues with occlusion.) b42 is in theory the fix -- take the cpu out of the equation so it can do other things (depth buffer on the gpu); reduce the number of boxes to sort by putting them all in one big box, etc. But there are trade offs to this -- we can't use that depth buffer for other things anymore, it'll need more ram, or the game will have to reprocess that megabox if something changes. btw, I'm self taught and have only a cursory knowledge of this stuff myself, picking up what I could while I worked here for the past 12 years and I am not the people that wrote it -- tested the results and pointed out things, though. So I'm not going to write an exam on it, frankly. No idea why you'd see the same results on significantly different hardware -- I certainly don't. Iirc in testing, hiding the interiors was simply the difference between 60 fps and 40 fps driving through West Point, on a middling system, so we did it. Easy trade, since most people never noticed. (3D fpses have far less to sort compared to 2d isometric games. Dramatically less. Old isometric games tended to be much simpler and cheat an awful lot to pull it off -- see how many floors you can build in the sims for example. GTA is also full 3D, so isn't applicable.) (and you're not wrong -- zombies are a significant cost themselves. Nothing is free.) (CPU sorts the tiles then passes the list to the gpu; the cpu isn't drawing the tiles unless you're using some sort of software renderer to make up for missing features in your gpu.) (Cores don't matter -- not everything can be multithreaded. You'll be limited by how fast the main thread or the rendering thread runs which will ideally be on different cores, but thats up to your os. And note GHz is fairly meaningless these days; generally cpu manufacturers use other tricks to get more operations per cycle, so you can't compare a 2.4 ghz system from 2024 to 2011 on ghz alone.)
  7. It really is just a cpu issue, as Krazmuze states. More individual items, more sprites to sort, longer it takes to process the list. Single-core performance of the CPU determines how fast that happens. There's not much else to it and we'll see what 42 brings to the table regarding this, as the point is to cache 8x8 groups instead of single tiles, as I understand it. You really shouldn't be seeing any issues with streaming data from your hdd. Any spinning rust after 2015 should be "ok;" any SSD shouldn't even flinch. But it depends just how much is going on in that chunk -- how big it is (individual items and carpentry can push em from 28 kb - 1 mb to 40 mb before the buffer gets overwhelmed, iirc) or what mods use LoadGridSquare.
  8. "bueldia foret-aye." Huh, must be Italian.
  9. Just note that the windows reliability report indicates hardware failure rather than a software issue -- and most of these crashes seem to involve textures. If you're having crashes in other games or programs, something like bad ram, a bad pcie lane, or gpu seems likely. (Power and driver issues can cause similar errors -- it's hard to diagnose.) Even if not, there's not much else we can do beyond point this out. :/ Went through this recently with a 3080. Took me months to accept it was the card, not something else, cause it was sporadic and only affected one game at first. It happens.
  10. Steam is having difficulties right now. There's nothing anyone can do but wait for them to resolve whatever issues are affecting their network.
  11. Unfortunately, I don't have any other suggestions. But if we ever find something, I've got this thread bookmarked.
  12. Sometimes it's down to custom cursors, desktop replacement programs, using the trails option for your mouse pointer, or windows getting a little confused when hdr is enabled ( windows key + alt + b will manually turn it off, then press the combo again to turn it back on, often restoring the missing cursor for me). it makes it really hard to know what really is happening beyond something is going wrong at the OS level with the way it draws the mouse pointer.
  13. Tbh, it could be a lot of things. It's hard to guess without a video of your issue. In general ... it could any of the following: - Mods (including those that claim to fix things) - A server running out of RAM - A server becoming overwhelmed for some reason - An admin teasing someone with admin abilities, such as spawning zombies - Desync between two nearby players and/or lag (wireless connections are especially prone to this) - If it only happens after a restart, then most likely it'd be from the server host (or hosting service) shutting down the sever improperly, without calling save and quit, causing file corruption - If zombies are set very high, this can also put additional strain on the server and cause culling to happen far more often; things can get weird If it's very rare, it'll be even harder to guess.
  14. Am I mistaken, or is there a rifle/pistol shot at the exact same time as they spawn? Makes me feel like there's some sort of intentionality there? Like an event or something that's designed to let you know it's happening. What mods are you using? Some of those twitch integration mods do purposely allow viewers to screw with you, right? assuming what you're showing in the video is identical.
  15. Turn off mod. If there's no problem anymore (ideally start a new game to verify this), then it's the mod.
  • Create New...