I've done exactly this. Well, not exactly, as I didn't load or swap images, just hide/show (they were always loaded).When creating a first-person, 2D, textured maze (in the style of Wizardry 6/7), would it be a bad idea to store each segment of the screen as individual sprites, which would be placed together to create the entire view?
![]()
Couldn't you draw an entire image, like this, and then cut it into little pieces, as in storing each highlighted segment here as its own image file, then swap them in and out as needed? You'd think that this would save space, because otherwise you'd need to store several variations of the view to account for all the possible variations. This would be pretty much exactly the same method you'd use to draw a wireframe maze, except that you're loading in images instead of manually drawing in lines. I feel like I'm missing something important here, though.
I remember playing that ages ago.Only game I ever finished though was this for a 64x64 frame size contest: https://phantomax.itch.io/totaqWhen creating a first-person, 2D, textured maze (in the style of Wizardry 6/7), would it be a bad idea to store each segment of the screen as individual sprites, which would be placed together to create the entire view?
![]()
Couldn't you draw an entire image, like this, and then cut it into little pieces, as in storing each highlighted segment here as its own image file, then swap them in and out as needed? You'd think that this would save space, because otherwise you'd need to store several variations of the view to account for all the possible variations. This would be pretty much exactly the same method you'd use to draw a wireframe maze, except that you're loading in images instead of manually drawing in lines. I feel like I'm missing something important here, though.
I mean it is hard to do, but remember that they got to this point by decades of refinement, if you go look at their first titles the implementation is a lot simpler. They've been at this for a long time. EUIII was the first as I'm aware to use this method of drawing country names.I will never make fun of silly Paradox names on a map again. This shit is hard.
Indeed, although others also did it before them (1997):I mean it is hard to do, but remember that they got to this point by decades of refinement, if you go look at their first titles the implementation is a lot simpler. They've been at this for a long time. EUIII was the first as I'm aware to use this method of drawing country names.I will never make fun of silly Paradox names on a map again. This shit is hard.
I think you're heavily overestimating the amount of effort it would take. Especially if you start form a premade template. That'd take like a week or two of intensive work imho, depending on the size and complexity of animation. You obviously dont need to animate every possible character separately, just have a body sprite + armor layer + weapon layer + hair on top.Thanks for your reply. Unfortunately what I want to make is more of an action RPG, with lots of character customization. So if you have 2 genders, 10 hairstyle options, 10 weapons, 20 armors... all animated in 8 directions with movement, attacks, etc... if you try to do all that in traditional pixel art and animation, I think you're looking at an effort best measured in years.
try using a texture array instead then, its the alternative method to atlasing. They can work together too but in some scenarios such as tiling textures we'd want to avoid an atlas and preference the array instead. I would check if your engine supports it (most do).texture individually from separate image files
It sounds like the easier method just from the name alone. I might try it out later, but for now I'm just gonna have all the textures sloppy and unorganized so I can make some visible progress that I can show off to someone. I've told friends that I'm trying my hand at gamedev and I don't want them to think I'm a slacker (even though I am).try using a texture array instead then, its the alternative method to atlasing.
No-nosense Football. You manage a football team. Buy new player, make tactics.
How can I improve the grafix for this game? I have no idea. Any suggestion?
The whole texture atlas business is a bit over my head right now, so for the time being I'm going to load each texture individually from separate image files, and worry about packing all of them later. Hopefully I won't have to dig up too much of my own work when I get to that point.
You've got the camera facing down so your draws are minimal, you've got good efficient use of tiling and all of your characters are reusing textures. Makes sense why it runs well.This old engine of mine didn't use atlases at all, it even had a separate lightmap per polygon yet it worked fine even on some on-board Intel GPU that a Pentium 3 PC i have from 2000:
Just a simple 2D game. I might not need to do it, but I'd rather do everything in a relatively efficient manner rather than being sloppy and relying on modern PC power as a crutch.What sort of scene complexity do you have in mind? If it isn't anything complex you may not need texture atlases at all.
This old engine of mine didn't use atlases at all, it even had a separate lightmap per polygon yet it worked fine even on some on-board Intel GPU that a Pentium 3 PC i have from 2000:
You've got the camera facing down so your draws are minimal, you've got good efficient use of tiling and all of your characters are reusing textures. Makes sense why it runs well.
You probably didn't need an atlas, and texture arrays didn't exist back then so it was probably best practice for what you were trying to do at the time.
Just a simple 2D game. I might not need to do it, but I'd rather do everything in a relatively efficient manner rather than being sloppy and relying on modern PC power as a crutch.
I mean its valid. I'm just recommending things on that its one extra thing in the toolbox that I find interesting as an alternative. As has been said countless times by game developers, you only optimise when it clearly appears what you've done simply isn't working as efficiently as possible. If your implementation runs fun there's no need it is overkill. That said I'm recommending it from a standpoint that I have run into these problems in the past and in the present, this is of course more truer for 3D games especially at the scale I work at (ie. lots of unique objects in a scene) in that situation you need those tricks to keep everything smooth. For a 2d game it comes down to how many unique sprites are being rendered at any one time. If working to limitations you won't need these tricks.I think unless you are going for something like early 2010s AAA 3D scene complexity you most likely wont see much of a difference in practice on modern hardware. Which is why i asked for the scene complexity.
I've written a similar program myself, but my resolution was a lot higher and limited to 32-Bit single core. I was able to get into the thousands of textures on screen and still hit 60FPS using individual textures not atlases or arrays. Textures are extremely cheap. If we use the modern methods though it can be even cheaper, depends on the scope.To give you an idea, i wrote a quick and dirty program that generates 4096 128x128 textures and then draws a 64x64 grid with them (4096 unique sprites at the same time on screen is most likely way beyond what most 2D games show - assuming 32x32 sprites you'd fit less than half of that in a 1080p monitor without any form of scaling and that is, again, about drawing all unique sprites at the same time):
I've written a similar program myself, but my resolution was a lot higher and limited to 32-Bit single core.
Well I mean I was looking at it from the perspective of this game would take years to develop, so by the time it came out that would be the norm as far as hardware is concerned sure enough I was right. But having your game stuck on windows XP due to a bug was a bad idea given its market share which is why I gave up, and well the 90s shooter fad pretty much died down in recent years I was trying to get it out during its peak, when Ion Fury released I was just like "nope not gonna get anywhere near how good this game looks and plays with this tech I've built" credit to Ken Silverman guy knows how to make an engine that can stand the test of time. If I could've licensed Build I would have. (I was under the impression the commercial license was separate from the source license you find online, I can't find reliable info on it but Ken says to do it you have to contact 3D Realms/Apogee)4096 512x512 RGBA textures would already be 4GB of VRAM data - that is 8 times more than the entire memory XBox 360 had and 16 times more than the VRAM PS3 had :-P
I'll repeat that saying indies say, Don't develop tools, develop games. Most of what you're going to want to do has been done and probably been done better.
Duskers has been on my radar for a long time and I bought it a while ago, but I'm yet to play it and thus unable to say if they have anything in common.Hey Bad Sector are you the Das Geisterschiff dev? I just picked up Duskers for free on the Epic Games Store. It looks like it has kind of the same feel as your game. And it looks like Duskers may have been pretty successful. Almost 2000 reviews on Steam makes me think that game must have made at least $500,000 in revenue. Have you played it? How do you think it compares to the geister games?
I haven't played zz's game, but Duskers is good stuff. One thing I didn't like thoughDuskers has been on my radar for a long time and I bought it a while ago, but I'm yet to play it and thus unable to say if they have anything in common.Hey Bad Sector are you the Das Geisterschiff dev? I just picked up Duskers for free on the Epic Games Store. It looks like it has kind of the same feel as your game. And it looks like Duskers may have been pretty successful. Almost 2000 reviews on Steam makes me think that game must have made at least $500,000 in revenue. Have you played it? How do you think it compares to the geister games?