What a nice board!
READ THE RULES https://zzzchan.xyz/v/custompage/rules.html
It's a conspiracy >>>/hikki/
Time for progress edition
>#8/agdg/ via irc.rizon.net
>https://matrix.to/#/+agdg:matrix.org via matrix programs
>Dev resources: http://8agdg.wikidot.com/resources
>Previous bread: >>47446
The first post that said this, I had no idea wtf he was saying. I think the word you're looking for here is isometric. Should find more resources searching for that than diamond map.
>using a plugin
>not writing it yourself
I know it's probably not as performant, but it's not that hard anon. I did it, and I'm fucking retarded.
>>61400 (nice digits)
this man is correct
I don't feel like I've done anything yet. It somehow looks like a lot of progress even though the entire map thing is only 56 lines of code right now.
I had the image that 'isometric' could be at any angle including top-down in pic related, but turns out it's actually a very specific angle where all the axis are equal. The More You Know™
You will never make a game. Give up.
Any of you fags work with idTech 3/ioquake3? I'm considering using it to just make game, instead of fucking around with Godot like I have been.
Sure, why not? Go for it, if you're a Carmack-tier C programmer and don't mind taking Stallman's poz license up your poop chute.
If Hue Engine is giving you trouble and you'd also like the freedom to do what you want with your code, I'd just stay away. What are you making anyway? Is this the helicopter anon?
>Go for it, if you're a Carmack-tier C programmer and don't mind taking Stallman's poz license up your poop chute.
I'm no Carmack-tier programmer, just a fag who wants to make a decent game without relying on Python or C# shit. As far as the GPL goes, you think I could make it so that the codebase is free to download, but the assets for the game have to be purchasable, like Doom did? I want to make some profit off of this anyways. If not, I could just set up some donation scheme and get money that way.
>What are you making anyway?
I'm considering my options. I'm thinking it'll be a Deus Ex-meets-Shadowrun FPS imsim, basically a conspiracy-ridden cyberpunk world with hidden magic. If not, then probably something from my own sci-fi universe I never got around to actually finshing.
>Is this the helicopter anon?
No, I'm the Konata fag.
I've been looking at the Irrlicht engine, too. I think that might be better, since it's got the zlib license, which is a lot more dev-friendly. I might use that instead, if I can figure it out.
Holy fucking shit just pick an engine and MAKE something. You'll never accomplish anything if you keep nitpicking.
Don't worry, I'm already working on the stuff that doesn't require an engine, like a common include file which has its own brand of basic type redefinition autism, i.e. uint8_t -> u8 and so on, because of my optimization autism, character sheet struct and a basic map struct.
You make it sound so easy.
Sounds like a big project. Not saying anything about you personally, but is there precedent for any one-man army developed 3D RPG/shooter/IMSIM or similar out there? I think that if I gave it a go that I could manage the game code and level design, terrain, building, and prop modeling, but that's about it. Character and enemy modeling and animation is both outside my skill set and seems like a staggering amount of work to me.
What's your plan there? Use an old engine or just go for a low-fi aesthetic in a new engine, with quake-tier low poly characters and simple animations or what?
Thinking about these things is what made me stick with 2d for my farm sim for now.
>is there precedent for any one-man army developed 3D RPG/shooter/IMSIM or similar out there?
Yeah, Cruelty Squad was made by a single Finnish fella, and Brigand Oaxaca was made by a single guy with a lot of help from drugs and alcohol. Now, I'm not sure if I could do all of it by myself, and I may have to do what Brigand Oaxaca did and mix and match different random free models off the Internet until it just werks.
I've got enough practice with game coding, though not as much as I should tbh. I don't think levels and terrain could be that hard, since I've spent a lot of time dicking around in level editors and map makers before. I could probably make a couple of props or buildings, nothing too complicated.
>What's your plan there? Use an old engine or just go for a low-fi aesthetic in a new engine, with quake-tier low poly characters and simple animations or what?
I'm still trying to decide between Irrlicht Engine and the idTech 3 engine, both of which are older engines. As far as general graphical aesthetic, I'll probably go with late 90's/early 2000's low-poly with really chunky, low-bit texture. For a good idea of what I want, look at Quake or Jedi Knight: Dark Forces II. Gameplay would be based on using combat, magic, or tech to defeat enemies, reach new areas, and advance the plot, like how it works in Deus Ex. The plot is basic so far, just that the main character is the average anon who suddenly receives a message from the Spirits of the Earth to destroy the evil conspiracy that rules the cyberpunk world, so he becomes a technomage to combat them.
>and Brigand Oaxaca was made by a single guy with a lot of help from drugs and alcohol
In fucking DarkBasic, no less.
Wew, that brings me back to when I started programming with BlitzBasic back when that was still around. I actually considered using DarkBASIC back then, but I decided to say fuck it and learn C/C++ and Pascal instead.
I can now accurately translate from tile coordinates to screen coordinates and back. I could have done something smart with matrices and linear algebra, but instead I just randomly threw X and Y values at it and divided/multiplied by tile size until it worked.
I know this answer has been answered already but I'm too much of a bydlo learning C/C++ to make mods for quack 3.
>You make it sound so easy.
It's not, that's why you stop wasting time with benign shit like engine choice and move on to the real work.
Did you manage to make anything with it? I've been curious about the language.
>Did you manage to make anything with it? I've been curious about the language.
Beyond basic shit I copied from really old school books, I didn't make anything of importance. I did it because of the structured programming meme.
The "easy" bit was more of a dig at this line
>Holy fucking shit just pick an engine (...)
Because all the engines out there are professional-quality and easy to use, well-documented and supported and completely usable and totally not in permanent beta or abandoned, and all with well-crafted, finished titles made with them to inspire us. So hard to choose just one when they're all this awesome!
I had a long, autistic screech written up but fuck it. Not gonna waste everyone's time with that plus I don't feel like starting an engine or license derail. I just want to say that I agree with you in that an engine is only one piece of the puzzle, and actually not that large of one either if you only look at what parts you actually end up needing. You will spend the vast majority of your development time and effort on content, art assets, asset pipeline, audio, scripting, and testing. However, an engine, especially these modern monolithic ones, will impact the rest of your development by forcing you into its framework and style. You see it all the time in these threads where someone is trying to do something dead simple, and having to jump through ridiculous hoops to make it happen, all the while stumbling over a poorly documented engine API, a proprietary scripting language, a convoluted build system, and being a programming newb on top of it all. So, I don't think choosing an engine is either easy to do or largely inconsequential, like "they're all fine, just pick one." But that's a post for another time.
It would be nice if we had a dedicated AGDG board that wasn't dead. A lot of these short back-and-forths between two anons in these general threads really deserve a proper treatment in their own threads.
A propos of nothing, I think classic shooter Tyrian 2000 was written in Pascal.
>It would be nice if we had a dedicated AGDG board that wasn't dead.
I hate how fragmented /agdg/ became after The Events That Were and now there's all this new shit interboard drama that is so tiresome.
Yeah, I have like three different agdg threads up from three different boards, its fucking tiresome. I prefer this one, since it gets the most activity, but there are splinters and shit. Some of these other board owners need to just sit down, realize this cell like structure doesn't work, and consolidate. I appreciate the slower boards, sure, it reminds of when 8chan first started out, but the utter lack of activity is kind of sad.
>Some of these other board owners need to just sit down
I agree with the sentiment but there's only two active /v/ boards, this and blacked.gov's and merging the two is never gonna happen. Even if you factor in /gaymoo/, that board averages 20 posters at best, 5 at worst, and most of them probably already crosspost here, even if you were to consolidate, as you say, these two, you wouldn't really get any noticeable increase in activity. Your best hope is that blacked.gov goes down forever or some shit.
sage for meta
But their according to their git, it is in pure C. Plus, it is a damn well written code.
That's the open-source variant of Tyrian, not the original version. It'd be like RCT was programmed in C because OpenRCT2 was.
* It'd be like saying RCT was programmed in C, excuse me.
The draw/art boards around the webring and other imageboards could easily and very well adjusted be grouped together, since there is barely anything to divide them other than genres. Hell, most drawfags either go pixiv/twitter or 4/ic/ because they need audience and critics
Bleh fuck this, I'll will later write a lose condition then I will call the quits with this stupid AA defense game. It is boring as hell for me fiddling around with it. The idea of being stationary all the time is not any fun for me.
Put the turret on a cat so it can move around.
That wasn't the goal of this game.
Made the map an actual map instead of drawing a nonfunctional grid, and added height levels. Height levels look like a big difference, but the only thing I changed was make the sprite be a cube instead of flat, and offset Y positions by height level when drawing them. Mouse doesn't align with the tiles yet though, I don't think the kind of straight conversion I've been using will work.
I always thought making an isometric game would be a pain in the ass compared to an axis-aligned square map, but so far the only difference is that I'm offsetting the sprites when drawing them. Otherwise it's all the same. The map is just a square, and I use this to get the screen position when drawing things:
float screen_x = tile_x*TILE_WIDTH/2 - tile_y*TILE_WIDTH/2;
float screen_y = tile_x*TILE_HEIGHT/2 + tile_y*TILE_HEIGHT/2;(TILE_HEIGHT is currently half of TILE_WIDTH)
Getting the tile under the mouse is something like an inverse of that, along with some offsets for camera position/zoom, though it only works on a flat map. I could turn this from isometric into an axis aligned game just by changing that translation function and redoing the sprites.
Here's a trick for animating a back and forth movement, you can also apply it to size or rotation or color or other things to make effects. It's fun to mess around with.
Looking really good so far, keep it up.
I believe screen coordinates should be unsigned ints (or int if your internal math could possibly underflow or something) because you will always be specifying a discrete pixel on a 0,0 to screen_width,screen_height grid. Correct me if I'm wrong. At least my framework requires all 2D draw functions to give their screen space coordinates in ints because of this.
The calculation will assume that x0y0 is the top center tile, so the left half of the map will get a negative X position. Some of the positions would become negative anyway when camera moves and sprites are drawn partially or fully off-screen. I mostly use unsigned values for states that don't need math, like tile IDs.
As for using ints, I would probably use an int if I was doing software rendering. I'm working with values that are relatively native for OpenGL, which doesn't exactly work like drawing in a paint program. x0y0 is at the center of the screen and x1y1 is at the top right corner, all the positions are on a -1.0 to 1.0 coordinate system so they turn into floats sooner or later and it's easier to think of the center of the screen as x0y0. You have to do some divisions to put accurate pixel sizes into that, whatever framework you're using almost certainly uses the same system but abstracts it away from you, I'll also do that for UI.
Interesting about OpenGL being from -1.0 to 1.0. Looking at my own code again, I'm using signed ints for tile/sprite drawing, and yeah, tiles half on the left or top sides starting drawing from a negative value. My tile map coordinates are 0-whatever though, but that's up to the designer.
Started working on spritesheet functionality. Currently every graphic is a separate texture, but obviously I want to draw many different sprites from the same texture atlas.
I wish Krita allowed you to define sprites in an image and export a Json file for them or something so you wouldn't have to define the sprite boundaries separately and "blindly".
>OpenGL being from -1.0 to 1.0
It depends on your projection matrix if I remember correctly. For instance, when doing orthogonal projection, nothing's stopping you from using the screen's or window's resolution for your left/top/bottom/right parameter. I think with perspective projection, you want your x and y coordinates normalized in the end anyway, so people commonly use -1.0 to 1.0.
Of course you can use whatever coordinate system you want, but you use a matrix or some other transform to map things into the -1/+1 scale in the end. For example when you're making a 2D matrix, most likely you're adding the screen size to it at some point, what it effectively does is causes all other values to be divided by screen size. So if you move something by 100, it actually moves by 100/screen_width, which represents 100 pixels in a -1/+1 system at your screen size. (A 3D matrix usually just skews the numbers according to the aspect ratio, and doesn't care about the actual pixel size.) The origin will always be at the center, if you want top-left origin instead of center origin you have to add an offset to the position, and also invert the Y position since positive y is up.
Holy shit I'm struggling with this. I'm sure this would have been easy if I were good at linear algebra, but I'm not so this is the most convoluted part of the game I've made so far. The cursor now accounts for tile height levels. It basically finds a tile from the bottom edge of the map that has the same X position as the mouse, then moves upwards until it hits a tile that has a higher Y position than the mouse, and then does additional checks to check for the edges. It can't detect under a block, which is fine since there won't be bridges or anything that would cause holes like that. I also don't think it would work for a rectangular map, but that should be fine because I plan to eventually make the map chunked and the chunks will be square.
Other than that I reorganized a bunch of stuff. There's now actual entities in the map as opposed to some arbitrary global variables and hardcoded draw calls everywhere. This allows them to be selected. Also tiles are now drawn from a single texture atlas, which somehow sounds more complicated than it is, all you do is move the texture UV coordinates. I haven't bothered to think about Z levels much so the entities just draw on top of all map tiles.
Got a little bit done this few weeks. Real life is still getting in the way and will continue to get in the way until probably mid-july for me. I'll try and get progress for a substantial demo for 7/7.
'Progress Report : Uncommon Time - Retuned'
-Worked on implementation of the vision-quest mechanics and enemy encounters. These encounters are not random. They actually trigger after 60 seconds (maybe 40 if it's too long) are spent in the space without interacting with any memories.
-Did an 'ambience' track intended for the mental landscapes of the vision quest arc. I had way too much fun causing and exploiting glitches in LMMS to create trippy shit. I really like how it goes with FP's cello-tuning track that's in the original game.
-Worked on the mapping of the mental landscapes of the party. Pic somewhat related, as it is a mental landscape, but it's not Saki's.
Any ideas how to save/edit information about sprites? For example which direction it's facing or where the center is. Most graphics programs don't have any support for metadata like that whatsoever.
My current idea is to create a separate image that has informative pixels in it, and then analyze it from the game. For example in pic related, the green pixels are the center which you would initially scan for, red pixels show how many tiles the building occupies horizontally and vertically, blue is the boundaries of the sprite, and in the top left corner is a color whose RGB values represent the building ID. That's just the idea I'm working with right now. If it works, I won't have to do anything from the code and can edit the sprite information and even building sizes from my image editor while editing the sprite.
Is there anything better I could be doing?
Just thought of a slightly different method. You could put markers at the edges of the blue rectangle for finding the center, that way you could put them in the same image, and also keep the markers in the same layer as the sprites which would make it easier to move around.
You can thank me later
Your pixel scanning shenanigans is going to noticably impact loading times unless you extract it at compile time. You'd be better off with a JSON file or some shit.
Made some shitty placeholder sprites today. All the animations and buildings are hardcoded tests and need to be completely replaced, so they don't count as actual progress.
I realized there's a problem that I didn't think of. If you have a building that occupies multiple tiles, how do you handle it's z level? It'll either go behind some of the ground tiles it's on top of, or overlap walls that it's behind. The only solution I can think of is to draw the sprite in vertical slices such that each tile it occupies has it's own part. It would be easy if the map was just ground with walls on it since then you could treat the walls separately, but the varying height levels are important for this game.
>You'd be better off with a JSON file or some shit
The whole point was to avoid having to hand-edit coordinates and ID numbers in some spreadsheet for every sprite and all of it's various forms and then do it again whenever something changes. That's what I've been doing so far and it's already tiring me out.
I mean obviously it would be baked in on a release version. It's not like that would be difficult, you can just dump the array where all the information is into a binary file and call it a day.
>how do you handle it's z level?
Wouldn't all its tiles need to be on the same Z level? It'd be hard to build on tilted land.
Yes, but consider pic related. Both tiles 1 and 2 are on the same horizontal level, but one of them needs to be in front of the building and another needs to be behind it. If you increase tile 2's z level, it's going to render on top of the tank and other tiles in front of it.
The solution I was thinking of is to split the building with the green lines, the middle part is drawn on tile 1, but the other parts are drawn on the adjacent tiles which would be behind tile 2.
You might want to sketch out several scenarios like the one you drew and make sure your solution handles all of them. Like, what if the tank were on the tile two tiles to its left and needs to be drawn in front of the "base" of the tower and behind the "arm" of the tower? You might need per-level or per-tile drawing layers or something. I'm not thinking too clearly at the moment, but I think sub-level layering might be something you want to do.
I don't plan to have situations where anything needs to go in front and behind a building at the same time, so that shouldn't become an issue. I think it should be solvable just by splitting the building in 2 sprites and drawing one of them on top of all other sprites within the same vertical slice.
It does get a little weird when something needs to go on top of a building though, for example pic related, a big entity is going on top of the pad from the back side. The right side of the entity needs to have the z level of tile B, but the left edge needs to have the Z level of tile A (since that's where the pad's middle slice Z level is). I think what I'll have to do is draw entities in vertical slices as well, and make each slice have the same Z level as the slice of the building that's on the same position. Entities can only go on top of buildings when they're entering the building, so I might be able to do a special rendering method for this situation, and don't have to account for it at all times.
Thoughts on Fusion 2?
I like your sprite.
All the information you're talking about can be represented as numbers in plain text, so it should fit comfortably in metadata.
>Most graphics programs don't have any support for metadata like that whatsoever.
GIMP lets you add a comment tag to images by navigating to: Image -> Image Properties -> Comment
Or if you prefer the command line ImageMagick lets you do that too: magick mogrify -set Comment "YOUR TEXT HERE" file.png
>avoid having to hand-edit coordinates and ID numbers
As opposed to converting them to colors and encoding them into the pixel data? I could understand doing that when visually mapping sprite boundaries but otherwise it's just tedious.
Also, why are all sprites NOT the same size? You're using a grid system so every sprite has to be drawn in respect to a single cell. In the case of large objects you split their sprites across several cells, for example in >>62404 your object is occupying 4 cells, hence it should be split into 4 separate sprites.
>your object is occupying 4 cells, hence it should be split into 4 separate sprites.
I considered it, but that would make it much harder to make the sprites especially when they're tall, and it wouldn't work for moving entities anyway.
>As opposed to converting them to colors and encoding them into the pixel data?
This is way easier than having to manage a separate text document. What if you want to make the tower taller? What if you want to add a tier 2 tower and you want it to be next to the original tower in the spritesheet, but there's no space and have to move things around? You have to figure out the new pixel sizes and X/Y positions and center points in the texture and insert them manually into a separate text document. With the meta pixels, you can just copypaste or move the border while you edit the sprite and it gets automatically figured out. This way I don't even have to make an association between the texture and the sprite info myself.
Anyway I just made it, it wasn't very difficult. First it looks for a red pixel as the starting point. Then it uses the immediately following pixel as the ID (which currently just uses the red value). Then it continues right until it finds a green pixel for the X origin. Then it goes below the green pixel and continues right until it runs into a blue pixel for the sprite width. Then go back to the red pixel and repeat vertically for Y origin and height. Only 2 of the blue pixels are actually relevant, but making it a full rectangle is clearer. Finally, it cuts out all rows/colums that are empty from the sides in order to optimize the size.
I decided not to put the tile size into the pixels after all since it has gameplay consequences and I want people to be able to customize textures with this method.
>text files are broken
Nobody wanted to see my shitty code anyway.
Is this going to be real time strategy or turn based strategy?
Real time, but it will be a bit different than typical RTS games. It'll also be robot themed, I just got the tank from a search engine as a placeholder.
Could I ask for some more specifics? This grid that you've made is intriguing. Will the terrain deform as you fight? What is this all in service of?
The main point of the height levels is that it's slow to travel up/down them, and some units can't pass at all without help. It's similar to Creeper World in the sense that you expand your territory through building paths and walls and stuff.
>Will the terrain deform as you fight?
I haven't decided yet if it's modifiable at all. I had this idea about a wall with enemies behind it and they come out at some point to throw the player off, so maybe.
Do a draw pass per z-level starting from the lowest, and draw back to front as usual. For buildings and such occupying multiple z-levels, do a separate sprite for each z-level. Entities and such get drawn on top of (after) terrain/buildings of the same z-level, like you'd do with any 2D game,
I counted >>62524 as yesterday's progress.
Today I haven't done much because I got annoyed at forward declaration. I tend to use whatever solutions seem simplest to me, and the simplest way to handle information about buildings and such is to make a global array of structs for all the info and using an enum with the relevant names for them. It's just there and requires almost no programming or parsing at all, and you can just get the information from the array whenever you want by using the enum names as indexes.
That's fine until you need to create 2 of them in different files, for example connecting the meta pixel parsing with building info. You can't do that because the array of buildings is in another file which is added AFTER the parser. The only way to solve it is to move all the info about everything into a pre-declaration file of sorts, which I already have to do for structs and enums which was already annoying.
So then I started wondering if I should just completely redo how I handle this stuff, have all the info in a separate text file and use a programmatic way to connect things, that would also work as a way to add localization. I thought it was a good idea until I realized I'd have to edit the parser every time I want to add a new property to anything. In the end I didn't make any headway with anything, but I guess becoming more clear about what I should and shouldn't do is progress in a way.
Today I had a small epiphany and realized that the concept of a "sprite" doesn't make any sense in terms of programming.
I want to draw terrain as big chunks of geometry constructed out of the map tiles. I want to draw buildings as multiple static slices (>>62404) depending on it's size. I want to draw entities (at least big ones) as slices that dynamically split as they move, and they have animations and 8 directions. I don't even know yet what's the smart way to draw particles. All of these things have very little to nothing in common in terms of the data and code for implementing them, so it doesn't make any sense to try make a unified "sprite" drawing system for them.
So now I'm in the middle of replacing the way I draw things.
>I want to draw terrain as big chunks of geometry constructed out of the map tiles.
Easy enough. Looks like you got that down already anyway.
>I want to draw buildings as multiple static slices (>>62404) depending on it's size. I want to draw entities (at least big ones) as slices that dynamically split as they move, and they have animations and 8 directions.
Did you see my comment here (>>62547)? You shouldn't need any dynamic "slicing" for buildings or entities, as long as they're constructed of separate sprites per each "block" of height they have. Say, a building may be two sprites, a radio tower three. A tank might have the chassis and treads as one sprite, the turret on top as another (now you can move the turret independently, too.)
Made a shitty mock-up. In doing so, I realized that you would have to draw buildings and mobile entities in the same pass as the static terrain and building tiles, sorted back to front, if you want them to occlude properly. I'm sure there's an easy solution to this problem; games like Tactics Ogre and Disgaea did the same thing.
Touched it up a bit, might be a little easier to understand.
Have you considered just using a z-buffer or is that too expensive?
All of your 'games' will be shit and you should just stop trying.
USER WAS BANNED FOR THIS POST Faggot
Just because your game didn't get green lit doesn't mean you have to take out your anger on anon.
Why not use something similar to Shovel Knight where the she objects exist on different Z levels and the perspective is done to make it look 2D? It would be extremely easy to render objects as behind or in front of one another that way.
Are floating points for C continuous or discrete? I am confused because I am getting conflicting answers when it should be well defined
This sounds like an exam question from CS101. Depends how you define continuous. Some people define that as "all those numbers in between integers like 1.1, 1.2, 1.300009, etc," In which case, sure, they're continuous enough. However, unless you're using one of those infinite precision libraries for scientific calculations, you'll find that floating point numbers will become discrete at some point like: 0.000000000002, 0.000000000003, 0.000000000005, etc. because the precision is limited. You may still be autistic if you think this matters for game dev, though. What are you trying to do anyway?
You'd have to do hundreds of "draw passes" over the map and all the entities and buildings every frame, that sounds pretty gnarly. I just move the tiles closer to the camera to sort them and let the z buffer handle the visibility, that's what I mean when I talk about "z level". I'm not sure how to calculate the z level of each block/entity if they were sorted by height, I suppose if you already know the max height level and map size then you could do something akin to (tile_height / max_height) + (tile_xy / max_xy / max_height).
Sorting by height level would get pretty complicated in many ways. Drawing (as in drawing in a paint program) buildings and entities as blocks like that would be hard, you'd have to make them pseudo-3D, and what if you want to make a robot that jumps around or otherwise moves up during it's animations? The animation sprites would have to get spliced in half in the middle of the animation, and you'd have to draw and organize the sprites for multiple layered animation. They do also need to be able to move up/down layers in general, and I want a smooth transition rather than an instant snapping.
What if I want to put hanging vines on a ledge that extend beyond the "block"? It would have to be somehow drawn in an inverted order, or I'd need "vines on 1 or the other or both sides" versions of each block and the blocks below them.
To me it just sounds a lot simpler to draw things in vertical slices, it's a single change to the rendering method that completely solves the whole issue.
>something similar to Shovel Knight
A game like shovel knight is significantly easier since you can have predetermined z levels and put sprites into the appropriate ones. In an isometric game like this the position and height of sprites determines who goes in front of who.
Your hanging vines are on the 1st and 2nd "z-level," which is what I am calling height in blocks. Since they are physical behind the house, they would get drawn first, and appear behind the house and roof as they should.
>Drawing (as in drawing in a paint program) buildings and entities as blocks like that would be hard, you'd have to make them pseudo-3D
I didn't really understand this but, even if not shaped like blocks or not obviously on a grid, in general, isometric game objects (terrain, buildings, characters, items, everything) are drawn as fitting within a x*y*z solid. A building might be 3*4*2. The PC may be 1*1*2. Your robot jumping issue would be solved by drawing from the lowest height level it occupies, doesn't matter if it's n units tall. Hell, just drawing sprites from furthest to nearest should really just take care of all of these issues, regardless of sprite size. I think >>62404 just shows a fundamental misunderstanding of drawing in 2D tile-based games. We're overthinking this. See my draw order pic here. If you make the "origin" of each sprite the bottom center, it's easy to calculate in what order it should be drawn relative to grid-snapped tiles.
Example of some "production" isometric sprites I doodled just now. See what I'm talking about?
Usually tilesets will have tiles like this for less overdraw too.
I'm calling it a z level because it's literally the z coordinate in rendering space and determines it's position in the pixel z-buffer. I guess "z depth" is more descriptive.
Oh you're drawing in map-oriented direction which is diagonally on screen. I didn't even think of that. That won't work though, pic related, the pad will draw on top of tile 7. Also if an entity moves from tile 6 to 14, it'll either be drawn behind 14 or prematurely in front of 7. In fact the sprites I've been drawing so far would have had the same problem if I put them into the correct Z depth, I'd have to draw all entities in vertical slices when they move.
I'll split the graphics into tops and sides later, they're not even supposed to look like blocks in the end, more like infinitely tall pillars. I don't think it's relevant to these problems though.
>but instead I just randomly threw X and Y values at it and divided/multiplied by tile size until it worked.
Big if true.
Nothing in the digital world is continuous, lad. You should know that by now tbh.
In case anyone is wondering why we draw inside the box with isometric stuff.
I had read that objects larger than one grid tile are usually split into 1x1x1 sized tiles, probably to avoid this issue, of 6 being drawn on top of 7. Or, splitting them vertically where they cross the grid. Pics related should do it. As for objects that can be at any arbitrary float x,y,z coords, I'd have to think about it some more.
I should say 31 on top of 7. 31 would be split into 4x4 tiles, each drawn after the terrain tile below.
Actually left side would probably be better split at the right grid border. This should eliminate any chance of partially transparent pixels on the edge between left and right giving you seams.
Tried changing the draw order by drawing from top to bottom but that didn't work. I'd say logic-wise, for each movable (float x,y coords) entity, when it comes up in the draw order, draw all terrain tiles it occupies before drawing it, then resume drawing tiles as usual. Should probably do the trick, if a bit messy.
In this case, it would go: 5, 6, 9, the one where I wrote Fuck, then the tank. Then 10 and the rest, skipping 9 and Fuck because they're already drawn.
This is kind of resembling the solution I was talking about originally.
I don't know if pics related make it any clearer, but that's what I was going for. Start from the tile closest to the screen, in this case the tank is moving into the lower 5 tile so it's included and thus becomes the center. For each half-a-tile that the sprite extends out of the center tile horizontally, it gets split into a separate slice whose z depth is moved backwards by 1 tile. You don't need to create multiple sprites, you can just draw it from the texture in separate slices and change their z depths to be on top of the appropriate tile.
I think I get your slicing idea now. My talk about breaking large objects up into 1x1x1 tiles was only for static objects like buildings that snap to a grid. Apparently that's standard practice for that sort of thing.
I couldn't get this tank occlusion problem out of my mind so I did some digging. Turns out there is a method of drawing for isometric games that tackles this very issue. It relies on sorting the tiles by a score priority = x*y*z, counting from the point furthest from the camera, say, back corner of the map (top of the screen, lowest height level). The tiles are then drawn lowest score to highest. Pic related shows it in action. Your green outline is right on the edge but I tried to fudge it to the right some. Taking the red dot I put as the "origin" of the tank sprite, it would be located at x = 4, y = 2, and z = 2, for a score of 16 (I'm pulling these axes out of my ass.) This places it nicely between the tiles it's standing on (scores 6 and 8) and that occluding block to the left of it, score 18 (3*3*2).
Whether this is easier to implement or more performant than a z-buffer, I couldn't tell you.
That's an interesting way to sort things. That method looks like it would still have a height problem though, like if there's 2 "blocks" on top of each other, the top block would get a higher score than some tall entity at the bottom in front of it.
I think most isometric rendering solutions take advantage of limitations that make them easier to implement, for example the ability to draw all ground tiles first and then everything else on top of that, the lack of smooth animations between tiles, entities that are on a single tile only, entities have a limited height, etc. I was looking at Tiberian Sun, and all the ground is sloped so it doesn't create "cliffs" that would cover anything. There's special rocky cliffs, but they can be handled separately from the ground, and they're thick enough that if the cliff is pointing up and someone is on the lower elevation, they can't go low enough to show up on the ground on the higher elevation. All they need to do is sort the cliff edge with entities the same way they do buildings.
I don't know anything about the performance of the z-buffer, you can just tell OpenGL to enable it and then use the z position to determine who appears in front of what. The good thing about it is that it doesn't matter what order you draw things in (as long as you don't want semitransparency) so it's very easy to sort things. That's why I prefer to think about things in terms of z depth rather than draw order.
Finished migrating everything to new render methods and reorganized stuff. Everything is now using the meta pixel parser which feels neat. Also made everything render on the correct z depth, it currently exhibits some of the z problems I've talked about. Entities draw behind the tiles in front of them when moving between them, and big buildings draw on top of the walls next to it.
I kind of want to do proper entity pathing before fixing those, would make it easier to tell which tile an entity is occupying and which tile they're moving into.
this iso game dev work is pretty impressive actually. keep it up anon.
>the top block would get a higher score than some tall entity at the bottom in front of it.
I think you can get around that by making the origin point of sprites be at the top instead of the bottom.
>I think most isometric rendering solutions take advantage of limitations that make them easier to implement, for example the ability to draw all ground tiles first and then everything else on top of that, the lack of smooth animations between tiles, entities that are on a single tile only, entities have a limited height, etc.
Well, yeah. I didn't want to mention them because it seemed like you're trying something new and those solutions wouldn't work for you. Most games I've looked at do all of those things. Most have only 3 height levels too: the flat terrain, a level for objects, player, entities, walls, etc. and a third for flying stuff like birds, bats, shadows of passing clouds, that goes over top everything.
I played the shit of that, that goofy first-person command and conquer game too, the fuck was it called? Also where's the anon who was making the ore harvester game? Dude better still be here.
Renegade, is the name of the first person one. First friend I ever had let me borrow it and we played it over at my house. Good times.
>Also where's the anon who was making the ore harvester game? Dude better still be here.
>'"OH SH.. HONEY, SKIPPY HEARD YOU! You're not supposed to use the 'V' word."'
I started trying to make the sprite slicing thing but it's somehow hard to think about because you need to cut 2 separate things (texture UV coordinates and the sprite itself) and you need to use the center position of each slice which changes when you cut the sprite from either side. Today was exhausting so I don't have enough brain for that.
Figured I'd take the time to try and learn modelling with Blender. I've made some simple shit any old idiot could make, but at least it's a good first day of progress. I also made this fugly and slightly creepy-looking smiley face. I'm actually surprised by how good the aquiline nose looks. My first big project will be some sort of pipegun like the Five Winds shotgun or similar, and I'll go from there.
Congrats on the start Anon. Hey, at least you're doing something with it! Blender since v2.8 is effin amazing. I predict it will eventually come to dominate in practically every category of film & vidya 3D DCC.
I see you're playing around with the sculpt tools. If you're thinking of trying your hand at weapons and such, look into polygon modeling, in particular hard surface modeling.
DBZ slices now work for buildings, it became much easier when I approached the problem from another angle. Previously, I had some pre-calculated offsets for positioning the sprite according to it's origin, and then tried to cut the sprite based on that position.
But instead of thinking about positioning the sprite at all, it was much easier to just use the sprite X origin as a starting point, and draw half-a-tile slices out of the sprite until the pixels ran out in each side.
I made some more Blender shit, this time a simple 9mm type of casing.
Thanks, I used the polygon modeller for this model.
My bad, a cartridge. I've had a little too much to drink, I think. Still, you get what I'm trying to make, right?
You're doing fine Anon. One thing it's important to do when you're starting out is to use references. Lots and lots of references.
There aren't any convenient free tools for profiling functions in C, are there? I just want to get an idea which functions take long to execute. I could do it myself but it would require me to add a macro at the top of all functions and replace returns with another macro, which sounds like a massive chore.
Currently working on some parts of the user interface, I think I will try to recreate the Morrowind GUI for the inventory and equipment.
Yeah, I'll have to, especially for all the details and such.
T-thanks... I tried my best, bro...
What kind of game are you planning to make?
Valgrind does it. You can view the instrumentation file in KCacheGrind. You're not trying to develop on Windows, are you?
A simple way would be just to time the functions themselves and display the results? First approximate accurate I'd say.
I do in fact develop for the OS that has >95% of videogame players.
But that's what I meant by adding macros. If I have to add something to every single function and replace every return statement and add a return statement to all void functions, it's going to be a lot of work and clutter the hell out of the code.
He asked if you're developing on Windows. You can develop on Linux and still compile for Windows and other OS, while benefiting from the comfy dev environment.
Anyone ever save any of TetraDev's vids progress?
This is as far as I got with a 2d physics engine. Rotation has been a giant pain in the ass and I still can't get it right.
I can drag and drop objects from the window, to other windows and to the game world.
A dungeon crawler, I don't know if it will be top down or in first person perspective, I'm leaning towards first person, it requires less sprites than a top down game.
Is it because you don't know the physics or because you can't model it to your satisfaction?
>don't know if it will be top down or in first person perspective
That's a pretty radical difference to not have decided yet.
Summer vacation started so I decided to binge on videogames instead of making progress. I'm surprised I managed to do something every day for more than 2 weeks.
Slices now work for units too, which inherently also works for units bigger than 1x1. It looks kind of interesting with the debug colors. There's currently a slight overdraw problem that's not visible in webm, the part in the texture that would be inbetween the unit sprite and the center of the "origin tile" is visible, it causes the blue meta pixels to show up sometimes. Can't be bothered to brain enough to fix it yet.
I did the think and now it works very accurately. The code is an epic disaster though and I definitely won't understand it a week from now, I barely understand it right now. It's just offsets and position fixes everywhere.
Mostly the latter. There's something off with the friction impulse in that rolling objects lose linear/angular velocity really slowly. Otherwise it's not bad for a first attempt. The game I have in mind will have linear 3D physics so It's no use spending too much time on it at this point.
this isn't really development related but more plot-wise, and a lot of you are going to call me a closeted turbofag for even suggesting this but i assure you it has nothing to do with fapbait/fetish material and is purely for character development.
i am considering taking the female side character in my game and making her a futa from a symbolic perspective. the idea is that she was created to be the perfect woman by otherworldly forces, but became corrupted by man from reckless gene editing and now has an extra appendage constantly haunting her. it will never be directly revelead in game and only slightly suggested from optional logs/backstory elements. i'm trying to think about how to make it work similar to Kaine from Nier: Replicant but I'm thinking about just abandoning the idea entirely if I can't find a way to add it without being considered a futafag or what happened with The Frontier and its huge amounts of autistic fetish material
>my game idea is about a girl who has a dick
>t-this has nothing to do with fetishes or fap bait
If we can spirtually remove the penis by purifying her body, and then make into a waifu, then yeah, it's not gay. Otherwise, you may have the penis addiction, my friend.
Another, probably better idea than giving her a dick would be to corrupt her womanly aspects in some fashion, specifically, motherhood aspects. Be this removing her tits (or nipples so she can't breastfeed), making her sterile (or worse, can have children but they're always stillborn), or hell, depending on how fetishy you want to make it, you could make her into a dyke instead of just giving her a dick. Curing her lesbian ways with your penis is optional, but encouraged.
she's not the main character and i truly want to avoid directly referencing it and shoving it in everyone's faces
>what happened with The Frontier and its huge amounts of autistic fetish material
It was one line about feet and some deathclaws in a hidden location meant as an easter egg. The mod turned out shit for different reasons than that. Also, your idea sucks, because you take an idea that is explicitly fetishized and expect people not to notice it.
I know it goes well with $current_year but I am fairly sure you can engage in displaying a womans grappeling with the ideal feminine or aprehension about literal and figurative maternity without attaching a dick to her.
Can we touch penises with her?
You are gay, fag. But to answer your question, why not just make her a really tomboyish girl who gets confused about herself? Oh and make some lewds of her, if you will.
>why not just make her a really tomboyish girl who gets confused about herself?
that's been the plan from the start, trying to find her place while beating the shit out of everyone and everything she encounters
i already have her designed in my head and am slowly but surely working on my drawfag skills to make it reality. there will be plenty of fan service but I won't make outright lewds, that's the community's job
Oh okay, that makes sense then. What kind of game is this going to be?
That's good enough for me.
right now it's a 2D Metroidvania, I'm still in the very early design phase since i can't program for shit, but i have a lot of the story and other stuff that doesn't require programming fleshed out already. my only regret is not actually starting work on it years ago when I actually had free time instead of sitting on my ass playing CS:GO. here I am five years later actually wanting to work on it while balancing a bullshit degree and a full time job.
>Just found out Allegro is superior 2D game library than sdl except there's no network multiplayer feature for it https://github.com/liballeg/allegro_wiki/wiki/Allegro-Vivace
>writen in pure C for pure C pure game developer. Absolutely 0 overhead.
>fags still shill for love2d
I kind of regret that I didn't learn C properly when I was younger.
It's okay anon, if you had learned it then you still would never have made anything of value.
What's the difference between that and SDL?
SDL looks more verbose i think. People have been using it more with C++ rather than C especially on the latest SDL version.
Found neat little music library.
Allegro works on even old systems like DOS and Atari ST. It doesn't need much hardware at all. SDL used to be okay, but now they're moving to SDL2 and it needs Xorg, GPU, and often they expect to use OpenGL even for basic 2D stuff.
I got some really old Atari ST RPG designer (hexaid) to build on my 32-bit ARM, but the game engine (hexplay) doesn't so it needs some updating. The code is really old, from like 1998.
Forgot the link https://www.audacityteam.org/about/desktop-privacy-notice/
Nice find! Tracks sound pretty good, and with a permissive license too. Wish it had FLACs though.
>Allegro works on even old systems like DOS and Atari ST
That's Allegro 4, is it the same for Allegro 5?
>they expect to use OpenGL even for basic 2D stuff.
OpenGL can accelerate 2D rendering as well as 3D so it's not a bad thing, but it shouldn't be a requirement if the game doesn't need it.
>The code is really old, from like 1998.
So the source is available? Start debugging and get it running you weren't gonna do any actual gamedev anyway
>acquired by musecorp
>which owns and distributes musescore
Shit, I think I have that installed. Is it filled with spyware too? I haven't seen anything about anything but Audacity with how recent this news is.
Speaking of acquisitions.
>The Linux Foundation and their partners are today announcing their intent to form the Open 3D Foundation to help foster 3D game and simulation technologies. As a key part of this new Open 3D Foundation, Amazon's Lumberyard game engine that started off based on CryEngine is going to see an Apache 2.0 licensed copy made available as the Open 3D Engine (O3DE).
>An "updated version" of Amazon's Lumberyard game engine is going to form the basis of the new Open 3D Engine being maintained by the Open 3D Foundation. Amazon previously made Lumberyard available on GitHub while keeping to a proprietary license but this move is indeed seeing Open 3D Engine made available under an Apache 2.0 license and "unencumbered by commercial terms and will provide the support and infrastructure of an open source community through forums, code repositories, and developer events."
>This new Open 3D Engine will be available on https://github.com/o3de/o3de . This is not to be confused with Intel's own open-source project called Open3D (Open3D.org) for dealing with 3D data and under an MIT license.
>O3DE with this updated Lumberyard code has a new multi-threaded "photorealistic" renderer, an extensible 3D content editor, and other modern features.
>Besides Amazon AWS being involved with the Linux Foundation's new Open 3D Foundation, other notable vendors involved include AccelByte, Adobe, Apocalpyse Studios, International Game Developers Association, Niantic, PopcornFX, Red Hat, and Wargaming, among others.
>The Open 3D Foundation website will be opening up today at o3d.foundation .
>It will be interesting to see how this Open 3D Foundation and Open 3D Engine evolve over the months ahead. In today's embargoed news release there was no real mention of this being about Linux gaming -- while being an initiative backed by the Linux Foundation -- but rather a move about fostering open-source 3D efforts across vendors.
>Amazon Lumberyard to date has been just focused on Linux dedicated server support with Linux client and editor support left in-progress for years. Given that Amazon Lumberyard hasn't been too widely adopted and from the Amazon perspective have been using it to try to push along AWS tech and Twitch game streaming, one has to wonder if this is just Amazon's way of trying to offload the development of the game enigne moving forward. If O3DE gets used by some major games, it will be interesting to see if there are any Linux ports to emerge considering the lack of Linux ports from existing Amazon Lumberyard games and Linux not being an officially supported platform. Amazon Game Studios also hasn't been releasing for Linux.
Is that good or bad?
Nothing of worth is being traded so the worst case scenario is that there will be a new and/or improved piece of free software.
Could it be, Unity's spiritual successor?
Always good to have more engines.
While the cancerous "partners" are contained to the new 3D foundation, I can't help worrying that it may open the door for their involvement in the Linux foundation too.
from the 20 minutes I spent with lumbayahd it looks like a pretty good engine, something that open sores desperately needs. although I can't overlook that amazog most likely has sinister intentions behind this.
The Lumberyard engine might be decent by itself but since it's push along:
>Twitch game streaming
Needless to say, I've got my suspicions about the place.
>The only games I've finished are gamejam games or school projects.
>All the games I care about making grind to a halt when I need to add art.
Why is it I can spend hours at a time working on a silly python ASCII game and I'm always eager to come back and work on more, but I sit down at blender to animate a run cycle for a "real" game and I immediately feel demotivated?
Could you be a furry in denial?
I believe in you, Anon. Keep working your ass off on your game!
Thanks for the vote of confidence.
Because in one case you're just having fun and in the other case you're treating it as serious work.
I don't know about Allegro 5 (I use v4.4 that comes with Ubuntu 16.04). I tried to read their site but couldn't find useful info. If it's designed like pic, then that's bad news, because then the library will automatically use software Mesa (slow!) if there's no supported GPU. And I'm guessing it is probably designed this way, because more and more modern things are expecting GPU even for stuff that used to work fine on 90's hardware with plain VGA card. I tried Chocolate Doom version 3 (uses SDL2), and it was horribly slow, whereas previous releases worked perfectly on all old 32-bit computers I used that didn't have GPU driver. Same thing with FS-UAE (Amiga emulator). It's just completely unusuable, whereas old UAE forks like E-UAE always worked fine. I recently went to build latest version of Frotz, and this guy is moving his code to SDL2. Maybe this one won't be totally unusuable since at most the graphics are just static images, but it still is useless overhead, and the maintainer seems to be someone who cares about older computers (he has Z80 homebrew project system stuff on his site).
So the future look pretty grim to me, because I absolutely don't want to be stuck needing 3D for anything at all. I'm not going to play thoses kind of games, so I don't need the driver dependency and library overhead. And the main reason I want to avoid it is because it limits my options for operating systems. NetBSD and OpenBSD don't have good GPU support for ARM SBCs, unless you have a raspberry pi (but I don't want those ones). This matters to me a lot because the future of Linux seems pretty grim. I'm already looking at other options, including writing my own simple OS (which will not be interesting to anyone else, since I like 8-bit computers and not anything modern).
As far as that RPG game goes, the source code is here: http://indigo.ie/~odonnllb/
The guy rambles on a lot, but he's interesting to read, if you're bored one day. And there's really no big need to compile a Linux version, because his original can be played in Hatari or other Atari ST emulator. Here's some screens and stuff: http://www.atarimania.com/game-atari-st-anoraks-of-doom-untramielled-adventures_11069.html
mesa on vesa is still faster than any VGA bottle-knecked assembler mode 13h bullshit from the 90s.
you should try writing homebrew for hand-helds or consoles, its a nicer trade-off for good APIs and low-level access.
writing pc graphics was a complete whore until graphics cards came around.
You can literally destroy a CRT with a well-crafted DOS program.
Ideally there would be some kind of wrapper to allow developing for both Allegro and SDL simultaneously, and the user simply chooses which library to compile with.
Why not help in funding or contributing to Godot and make it less shit?
I suppose that means I need to find the fun in the stuff I don't want to do. Or at least enough fun for me to get started.
Hopefully by the end of the week I'll have a run cycle completed. Regardless I should post my progress up to this point since it's something I haven't done yet.
It's nice to be back in an /agdg/ thread after so long.
I guess Doom was mode-X instead of 13h, but I still can't see how Mesa would be faster than either, given how it's an extra layer of abstraction. And for higher resolutions graphics you can can use a VESA driver in DOS (some games needed this).
Anyway DOS mode 13h graphics were really easy, because it lets you address the video memory as a linear buffer. Long ago, I did some small games and demoscene stuff in Turbo Pascal and a little bit of inline asm (mostly the putpixel and some inner loops). It gets more hairy if you want to use the other graphics modes that have bitplanes. Amiga too, it uses bitplanes, but I think the Atari ST was just a linear framebuffer. Amstrad CPC was also kinda weird, and when I was a kid I couldn't understand why POKE'ing to video memory created horizontal "bands" of pixels (like in pic), instead of just filling it up in the same order as the memory (I didn't have any hardware books back then, just the BASIC programming manual that came with the computer).
You could technically also blow up a CRT back then with xvidtune, so they put warnings all over the program. I guess this won't be a problem with LCDs though. The big advantage CRTs had is they could effectively give you any resolution (within its supported frequency band) and so games and emulators didn't need stuff like 2x or 3x scalers or whatever to run in full screen. When I installed Linux, I played with the SVGALib version of Doom (Linuxsdoom) which was very fast even on my 486DX-33 with 8 MB RAM. But now Chocolate Doom v3 isn't even playable on 1 GHz ARM Cortex-A7 with 2 GB RAM. So clearly the Mesa overhead is huge!
It should be possible, but someone has to do it (you maybe?) I had the idea of making a small library for Linux fbcon that uses the same API as the old SVGAlib and/or Borland BGI. Those were pretty simple!
> ... I sit down at blender to animate a run cycle for a "real" game and I immediately feel demotivated?
>Hopefully by the end of the week I'll have a run cycle completed.
It could be that on some level, you know that you've bitten off more than you can chew, don't see the project ever coming to completion, and this is demotivating you. Now I don't know what you're making and if I'm just talking out my ass here ignore me, but, this reminds me of a post I saw somewhere in response to some "I want to make a 3D MMORPG by myself or maybe with a friend" post. The response was basically for the OP to complete, to production quality, one 3D asset whether it's a playable character or monster or whatever. Start from concept to 3D model, to texture, to all of the animations it needs: walk, run, sit down, stand up, attack, take damage, die, etc. Sounds and shit too. Time exactly how it takes to do all of that. Then, multiply it by how many characters/monsters the game will feature total. Then multiply by 1.5 because nothing goes to plan 100% of the time. Then add some time for programming and environmental design/production, so multiply by two or three. You might end up with a figure like 10 to 100 years to ship it.
Do you think your problem is something like the above? If not, you may just have a dopamine receptor issue. Over-stimulation can cause game dev work to feel like torture compared to the stimulation and pleasure you're used to receiving just by sitting in front a computer, and small achievements like tasks completed can mean nothing at all to you compared to orgasm and bing bing wahoo explosions numbers getting bigger.
If you don't think that one applies to you either you might just not want to make game.
Have you seen DirectFB?
The game I'm making is a wave based first person melee combat game. There is a single level. I need to create an un-polished placeholder enemy to suss out the fun in the concept, but after that I'd say four enemies minimum to make it work, ideally seven. It doesn't feel overwhelming.
Overstimulation could be the problem, as much as it pains me to admit it.
>Linux Foundation decides to throw their money at a game engine
>it's Amazon Lumberyard
>aka No One Cares: The Engine
>doesn't even support Linux
>owned by Amazon
>we're totally going to add Linux support
It's probably some kind of dumb internal politics move or way of giving nonprofit money to Amazon for an engine so disliked that Amazon tried bribing developers with multiple free alexas each to use it.
It's a shame that no one gives a shit about software rendering anymore. I get it, most computers have GPUs, but it's still a cool feature for retro games and will absolutely attract autists to your game.
Software rendering is almost completely useless, the only reason to do it is if you personally find it interesting to program such a thing.
Completely useless things are often cool and may have unexpected benefits in the future.
Billions of people do things they do not find fun or stimulating every day all year. That's called their job. Maybe if you could find a way to see the boring stuff in your project more like a job that you *have* to do in order to achieve your more interesting goals, it will go down easier.
I've never had a problem doing my job.
Though I think the real secret is for me to stop posting and get back to animating.
Good enough for a placeholder.
Good job, Anon. I told you you could do it.
I'd say that's above average, I've seen some real shitty cycles, it could use more frames but the motion seems good. well done.
t. ignorant nodev judging by appearence
That's actually pretty good, props.
Since you're doing humanoid characters you might be interested in stealing animations from Mixamo, they have walk/run cycles and many others that you can just use instead of reinventing the wheel animation wise.
I tried it today, because there's some Ubuntu packages. I found out the hard way that you shouldn't blindly run directfb programs like dfbmaster, because it locks the screen and even Alt-SysRq doesn't work anymore. Allegedly this also can happen if a program crashes while using directfb for video (had to search a lot about how people were using directfb beause it's not very obvious how to from reading the docs). One thing that worked great was "links2 -driver directfb" but only after creating a ~.directfbrc with:
(to match my /dev/fb0 settings, because directfb doesn't detect this properly). Then I tried some SDL programs, and none of those worked when I did "export SDL_VIDEODRIVER=directfb" and complained they couldn't find a video device. Of course they run fine with SDL_VIDEODRIVER=fbcon, so maybe Ubuntu's SDL wasn't build with directfb support. Well I guess I'm not gonna build it myself, since I don't like how the library can lock the system to where you can't recover with Alt-SysRq. But maybe there's some code from directfb I can steal for my crAPI purposes.
Pic unrelated (it's dMagnetic, an interactive fiction engine).
That's the Linux foundation for you. Seriously, have they ever done anything useful?
Maybe paying the core devs counts? Although that's so basic I don't think it should.
It's so choppy because my computer struggles to run Blender and OBS (and a bunch of other stuff) at the same time. The animation is all done with splines so it should be smoother in-game.
I'd forgotten about Miximo. I don't think it will work for my situation, but I can always use it as a reference.
Anyone want to team up and make a superweapon that can destroy the sun so it's not so fucking hot every day? I can't make progress like this.
try getting A/C, faggot. and come back when you have a tropical storm dumping the fucking ocean on your house.
i can't sleep at night because my bed is too hot, then when I wake up I'm freezing cold from the A/C. I can't win
Just wait until Bill Gates and his team of scientists block out the sun with literal chemtrails, then you'll be nice and comfy
And that's not a shitpost, that's actually a real, proposed plan. Spoilered and saged because offtopic
Nice! Is your game going to be a platformer, or is that just a test scene you've got there?
>this gas is trapping heat on the planet
<oh no what do we do?
>put even more shit in the atmosphere!
Let me get this straight, they actually considered creating an artificial nuclear winter? Might as well go for the real thing at this point.
TGIF waifus and gents, life is gonna get a little less hectic for me once the weeked is over, but I'll still be sparse in this update. Not too much to list, but I have got a significant amount of progress done, mostly due to crunching some content when I thought a demo day was gonna roll around. Going through smug's /AGDG/ thread showed me that it took me over half a year to get out of Bel Canto once I got in it.
'Progress Report : Uncommon Time - Retuned'
-Made some changes to dialogue in act 1:
----Adjusted some of Meirin's dialogue for Nuclear Teagan. To avoid spoiling too much, I'll just say that Meirin's dialogue in a specific section needed to be more angry-sounding.
-Progress made for the post-Nuclear-Teagan parts of act 1- almost done implementing act 1! after that, All I just need to do for it then is polish, and then the art for everything else.
--Almost all dialogue prepared for the end-cutscenes for act 1.
--Various dialogue prepared for Teagan-POV sections of act 2.
>right punch while moving the left leg forward
That's not how punches should work.
Either have the leg on the same side move and either contact the ground with the punch or after, or move the opposite leg but have it touch the ground right before the punch starts.
How 2 learn c++ and make geim? Pls respond
That's better, but it still looks kind of weak because of the limpy hand and the lack of hip movement. I couldn't find any video reference.
In a strong punch like that you're going to want to use your hip, so the right foot would turn outward as you step and then straighten out and lift the heel of the ground as the hip turns counterclockwise for more force, also you're supposed to lock your elbow when punching, so it'd either stay straight for a bit after the contact for a straight or stay at ~90º for a hook.
Usually for human stuff it's a good idea to try out the movement yourself until it feels right then redo it slowly while paying attention to individual parts (e.g. arm movement or feet positioning).
Usually the best way to go is just starting with baby mode then going for increasingly harder projects. Just start with making an empty window, then making a box move, next go for pong or something.
For 2D there's SDL and >>64548 because realistically you won't want to fuck with low level graphics, but everything else is on you.
Thanks for the good information, I appreciate it. I'll keep it in mind for future animations but I'm not going to spend undue time polishing what's meant to be a placeholder. If anything I've already spent too much time on it.
Make the punch faster and have him twist his torso in the same direction as the punch, it looks like a girly slap right now
i need direct control of each individual pixel.
am I better off making an engine from scratch or is there a good alternative?
nobody throws a punch with their back and head perfectly perpendicular to the ground.
With the problems I'm having with exporting to gltf2 I'm probably going to be re-doing it anyway.
First, your performance is going to be miserable.
Second, most engines will let you blit arbitrary data to a surface and then render that surface. You're much better off using a tile-based renderer though.
Make your entire game in a pixel shader. Or you could ask the Noita guys how they did it.
Are you going to request a Steam Deck devkit, anon? Just think: you could own a rare piece of hardware, a piece of memorabilia for the failed Arch Linux console.
I can't even afford to upgrade my PC with the latest AyyMD mene tech.
I was thinking about how could you handle savegames in a game that has procedurally generated dungeons?
>just store the seed used to generate the map
>store the generated map
Now the first solution is superior on savegame size (you just need to store a 32-bit number instead of kilobytes or maybe even megabytes of generated data). However, generating a random dungeon is the exact kind of algorithm, where even a tiny little change can cause drastic changes in the output. So in this case you either can't change the generator algorithm (not even bugfixes) after release, or you lose savegame compatibility with older versions. I don't like either.
One alternative I was thinking about is to store the version used to generate the map, and in newer versions of the game include a copy of every previous version of the map generator, but this will quickly lead to code bloat and an unmaintainable copy-paste mess.
Any other idea to get savegame compatibility without causing a savegame file size bloat?
The way to handle procedurally generated dungeons is to shove them up your ass, anon.
Ape Blender's version compatibility system,iirc it basically stores trait information about the version the save was in and the later versions have tools to convert from such to whatever is now in place.
I think they were calling it SDNA but they might have changed the name for it somewhere along the line.
You might also follow the 12 principles of Animation, Anon. Just b/c it's vidya doesn't mean it's not also animation.
You mean this?
As far as I can tell, this is more like something to store and load different versions of structures, and not something that would help me with having to run completely different algorithms on a field depending on the version.
>savegame file size bloat
This is probably the most useless optimization you could come up with. It increases your code complexity and proneness for bugs for basically no benefit at all, the amount of space you can save will never be worth it.
If I had anything worth requesting one over I just might.
Store the seed but also store explored dungeons explicitly so you can keep track of what the player has done in them.
Savegames is for chumps. Don't store anything and just give the player a long ass code to write down. Then he will fuck up and have to start over from the beginning. It builds character!
>you lose savegame compatibility with older versions
Simply write a one-time-use standalone tool that converts a save file from an old version to a new version, and only have your game detect the save file version and either accept it or reject it with a message linking to the tool. Also read below.
>Store the seed but also store explored dungeons explicitly so you can keep track of what the player has done in them.
That is a great point, here's a simple example I thought of:
Let's say the seed generates the dungeon design, the enemies to be defeated, and the items to be picked up. If a player saves at the beginning of the dungeon where nothing has been changed, simply save the seed. If a player picked up an item, save the seed + the position of the picked up item, so that on load while the dungeon is re-generating you can simply go to said location and clear it, similarly for defeated enemies.
That is provided that the dungeon design is not changed, because if it is you will also have to save the changed areas. You'll have to figure it out.
Fixed save points before/after dungeons are also a good idea.
Even if you're still implementing in-dungeon save, you can always instruct your players to save at marked fixed locations before updating. K.I.S.S.
I wonder how practical that actually is nowadays. Most games have items or currency or more complex states that would be very hard to fit into a level code. Each character can represent 64 states without requiring esoteric characters (01234567 89abcdef ghijklmn opqrstuv wxyzABCD EFGHIJKL MNOPQRST UVWXYZ-_), which is not even 1 byte of storage.
2 = 4,096 states
3 = 262,144
4 = 16,777,216
5 = 1,073,741,824
6 = 68,719,476,736
7 = 4,398,046,511,104
8 = 281,474,976,710,656
6-8 seems like a comfortable amount or characters for a save code that you might write on a piece of paper. But even at 8 you only have 48 bits (6 bytes) of storage. That's an ok amount of space if you just want to store a couple item counts and booleans, but if the game is procedurally generated then there's not a lot of space for a seed.
I'm retarded, it's much easier to think about if you just treat each character as 6 bits.
1 = 6
2 = 12
3 = 18
4 = 24
5 = 30
6 = 36
7 = 42
8 = 48
9 = 54
10 = 60
You also could give the code with a space in between, for example "ABCD EFGH" which would be easier to read than "ABCDEFGH".
>Store the seed but also store explored dungeons explicitly
So something like minecraft? But that would be pretty much like the save the generated dungeon as-is (I won't have such big "open world" dungeons where it's worth to break it down into smaller chunks). I would have not visited dungeons (which require no save data at all), and visited dungeons that well, store the generated dungeon. If it's a bigger one, it could be done per level or something like that.
>Simply write a one-time-use standalone tool that converts a save file from an old version to a new version
Except that's not possible in my case (I have a seed A + generator A, and I would have to find a seed B that with generator B generates the same dungeon as A).
>[...] That is provided that the dungeon design is not changed,
Yeah, but that's the problem. If you change the dungeon generator, just a tiny little bit, it will generate completely different dungeons.
>Fixed save points before/after dungeons are also a good idea.
This help if you can't go back to a previous dungeon, otherwise you'll end up in a state where if you go back to an old dungeon in a new version of the game, it'll look different. But at least it won't break the game, like if you were to save inside, and what used to be a save point in the previous version suddenly turned into a massive block of wall.
To be honest, I'd recommend against using small and capital letters, because unless your players are linuxfags, they'll just mess it up. That leaves you something like 36 possibilities per character, which is nothing. Also factor in that you'll need some kind of checksum, or even better some error correction code, to check the cases when the user mistypes the code. It was good when all the state you had to store was the level number, and maybe some bools, but as soon as you need something more complex, it won't work.
To be honest it's not only the savegame, but also the loaded game.
But yeah, as long as I'm not making a 3D infinite voxel game like minecraft, it's unlikely that this will cause a problem on today's HW.
>36 possibilities per character
That's only 1 bit less, so 5 bits per character, 8 characters would be 40 bits.
>check the cases when the user mistypes the code
I didn't think about that, you could just type garbage and it would load a save with some random state.
Ignoring the invalid code problem, I tried to apply it to Spelunky HD, assuming you get a new a save code between each level. There's 16 different unlockable items (like climbing gloves) and 3 different items you can wear (like jetpack), so 19 bit flags for those. It's impossible to store all the items you can carry, but maybe you could make an exception for a key item like the city of gold scepter. There's 10 different levels, 4 bits will be able to represent 16.
That's 24, so 16 left. You need to store bomb count, rope count, and health, at most you would be able to store 32 of each item and have 64 max HP, or 16 max HP and 64 each item.
However if you used both uppercase and lowercase characters in the code, you'd have 24 bits left. The game has 99 cap on items and HP, and 21 bits is enough for that. So there's still 3 bits left, maybe you could use it for other significant held items like eggplant and plasma cannon.
It won't be able to store the seed, but that's not necessarily required since you get the code in-between levels. It would change the seed if you re-load the game which may or may not be desirable.
So it's almost doable. The reason why "almost" is that it's missing one important part: money. You would probably want almost a whole integer for the money count so I don't see any way to store it accurately. You could map a value into some kind of curve, so 1=1k gold, 2=2k gold, 3=5k gold, 4=10k gold, etc, rounded down from your actual money count. It would be inaccurate but maybe you could represent it as some kind of money bank in-game.
Actually I just remembered that there's also your favor with Kali, and whether shop keepers are angry. The shopkeepers can forgive you after a time so it's not just a boolean. I don't know how the Kali favor works either but I think it can go quite high and also be negative. It's probably pretty hard to store these.
meaning that one project you started years ago, never finished but still keep around to haunt you.
I still had autism left so I did the opposite: how many characters would you need for a proper Spelunky HD save game?
There's 41 different items you can unlock, equip, or carry to the next level in your hand. 3 of them can be both equipped and held so 44 bit flags.
4 bits is once again enough for the level. I also realize that the worm can be entered from 2 different levels, but 4 bits has room to spare so it's ok.
HP, bombs, ropes, again, the cap on all of them is 99 so you need 21 bits.
For gold, I think people have gotten multiple millions of gold (I saw that a world record was 3.5m but that might have been spelunky classic). There's no good reason to store values less then 100 since the smallest treasure gives 100 gold, so the max value we need is, let's say, about 50,000 for 5m gold. 16 bits can handle up to 65,536, or 6.5m gold.
Shopkeeper forgiveness increases when you exit a level, so you shouldn't need more values than there are levels, i.e. 4 bits.
Kali gives final reward at 32 favor and final punishment at -48, but I don't know what the max limits are. 7 bits is enough to store a range of -63 to +64.
So for a full save game without seed, you need (44+4+21+16+4+7) = 96 bits assuming I didn't make a mistake. That's precisely 16 characters which would be pretty long: ABCD EFGH IJKL MNOP
Another 4 characters would be able to store a seed between 0 and 16,777,216, which is probably good enough. So the full save game WITH seed would look like: ABCDE FGHIJ KLMNO PQRST
Why aren't you working on it if it's haunting you?
I made a clicker game that I've wanterd to re-do many times over the years but never got around to it. It always concludes with "I'd rather do a completely different clicker game than redo this one".
I know about The Illusion of Life and the 12 principles and I have for years. I also know about The Animators Survival Kit, so you don't need to suggest that to me either. The animation was so bad because it just existed to signify "attack", it was never meant to look good.
There are dozens (probably more) unicode characters that're easy to write down, like all of bopomofo, the unique greek letters, and all those pictorials they have now. That ought to provide enough space for, say, a flash game level of complexity. Why limit yourself to just ascii? I guess at some point the limitation becomes how long it would take to actually find and enter the characters. Furthermore, I think you could easily expect someone to write down ten groups of three-digit numbers, for instance--it's not like we're asking people to remember these like they were phone numbers or something. Sure, it'd be a pain in the ass, but it seems that's the point.
For each additional bit of storage, you would have to double the amount of possible characters, even for 1 more bit you'd have to make half of the characters be some weird symbols. It doesn't seem like it's worth it. If it was only intended to be copy-pasted (for sharing online or whatever) then that's a different story, in that case you could use the entire Chinese character set and the amount of characters wouldn't really matter either. You probably don't want to use emoji since some websites may replace them with icons.
>it'd be a pain in the ass, but it seems that's the point
To me the interesting part of this concept is that you could store save games on a piece of paper and/or give them to someone else. Adding unicode characters would prevent you from typing it on your phone and keyboard and it would just become a lot harder to understand. If you have to type A, it doesn't really matter how/where you write it because you know it's a letter of the alphabet. But if you have to type § then most people will probably have to draw that like a picture and interpret it visually because they don't know wtf it is.
Well Faxanadu used mixed-case characters and it was fine. It was a pretty long code, but not too long to write down. It's enough to store player's XP, Gold, items, location (always a guru's house since you can only save there), and other state bits that need to be remembered.
For a game with dungeons generated from random seed, you just save the seed. If you change the algorithm, then those places change but it doesn't matter beause the player can only save at static locations (like an inn at some town).
>store mapgen version string and hash (to have your cake and eat it too, treat mapgens as selectable external libraries, and let the user download them at his own option)
>store seed value
>store changed map elements as delta information instead of the entire fucking map; this gets less efficient if too many changes occur so you might want to store "map nodes" as a fallback
>save exploration data as compressed 1-bit quadtree or PNG data per floor
>save activated entity stats (location, facing, etc. in addition to HP/status) and event flags
>load and regenerate in the same step order
If you're doing vertical 3D stuff with real time action and non-grid geometry it'll be the same principles, just more complex (store vertex groups or generate a node list instead of a quadtree for exploration, for example)
>treat mapgens like plugins
Interesting, But this way I only have to keep the plugin interface stable, and not ship a zillion version in one executable.
What if the user opens an old save with a new game, and he wanders to a new dungeon? Use the old mapgen? You'll miss updates. Use the new one? You can easily end up with saves that requires 100 different mapgens to load.
>save delta info
Yeah, if I were to choose the "store the seed" way, I'd do it like that, Just store what changed, so no save data = default values. I once wrote a system like this, except the map wasn't generated there. No need to store data about indestructible walls or objects in their default state
I don't think I would go beyond grid-based 2D. The only 3D I'd do is to have ladders that take you to an upper/lower level. But they can be pretty much treated as separate 2D maps.
>What if the user opens an old save with a new game, and he wanders to a new dungeon? Use the old mapgen? You'll miss updates.
This is where a save converter program could come in handy. A more complex (and more satisfying) option is a hooking system where you can check menu boxes for content that the main game feeds the mapgen. Each content update adds one or more boxes to the list, with content dependencies indicated by metadata. This is sounding a lot like a comprehensive mod platform now...
A lot more characters can be added to that list while still remaining non-esoteric:
There are also these characters but they're omitted because they look ambiguous and/or can get autocorrected by some regional keyboards:
So the total states for each character are: 10 for numeric digits + 26 for lowercase alphabet + 26 for uppercase alphabet + 23 special characters = 85 states (or 59 states if you're using case insensitive alphabet).
>I have a seed A + generator A, and I would have to find a seed B that with generator B generates the same dungeon as A
Then your only choice is devising a formula that converts seed A to seed B.
>This help if you can't go back to a previous dungeon
Good point... But even if you store visited dungeons in their entirety a similar problem will still arise: let's say a user saves between dungeons, updates the game, then goes on to the next dungeon only to find that it has been generated in a different manner than expected.
I think that by changing the generator you're pretty much creating an entirely different game, for better or worse. It would make sense then to simply disallow updating to a new major version of the game mid-playthrough.
>>check the cases when the user mistypes the code
>I didn't think about that, you could just type garbage and it would load a save with some random state.
Think of the possibilities though! You can enter a random code and get thrown halfway into a completely new playthrough, and you have to explore and make the best of it.
16 characters is not that long for a large complex game, where you expect players to play for long periods of time and rarely need to save/load. Besides, if the player is on PC or mobile even he can simply copy the code and paste it into a text file.
However this begets the question; should your game really be that complex? If you can simplify your variables, and in doing so simplifying the gamedev work and save code length, then why aren't you?
>To me the interesting part of this concept is that you could store save games on a piece of paper and/or give them to someone else.
>If you change the algorithm, then those places change but it doesn't matter because the player can only save at static locations
Good idea but only if the player can't backtrack, because then he would be visiting completely different dungeons than the ones he already cleared. See >>66356
Checking for invalid save codes would actually be pretty simple. If you use a crypto algorithm to scramble the bits, it would be impossible to deliberately forge the bits without using the crypto algorithm and key. Then if you include 8 extra bits in the code and only treat it as valid when all those bits are 0, there would only be a 1 in 256 chance that any given code is valid, in other words you'd have to try (on average) 256 times before you get a valid code.
>download unity decompiler for shits and giggles
>decompile various games I have downloaded
>decide to take a look a Dusk's source code
This is just a fraction of the player's update loop, guys. Friendly reminder that code quality has absolutely zero bearing on how successful your game is.
Keep in mind that apparently the game was originally written in JS and then the decompiler I'm using automatically converts it into C# I think which is why the syntax looks funny in some spots, but this is still pretty shit no matter what language you're coding in. Almost gives Yandev a run for his money.
If it works and does what it's supposed to do, it's not shit. Dusk is a Quake or Blood clone, so it's not going to be performance-heavy in any stretch.
Bad metric if you're trying to defend Dusk. I remember on my lower-end PC from a few years ago, it mostly stayed around the 45 FPS range unless I was just in a really quiet area.
Even now, on my Ryzen 5 2600X, it uses around 15-30% CPU. For comparison, Q1 on the Quakespasm port uses 0.7% CPU at the very highest, and it peaks when I shoot explosive barrels. I'm aware that some of it is performance overhead from Unity's shit engine but I'm sure that calling GetComponent() every frame and not delegating functions to state machines or other abstractions doesn't help either.
Keep in mind that YandereSim also doesn't have a particularly high CPU bottleneck and performs like shit mostly because the game doesn't have any LOD scaling/occlusion culling in place and uses high-poly assets for small objects.
I didn't know that existed, how well does it work?
I wanted to edit/get assets from some porn games
I use the free version which just allows you to read source code and not save anything to disk. It works for most games and all the class structures/variable names are intact, obviously no comments. There's another tool that extracts assets from Unity games, I believe it's called uTiny. I've had slightly less luck with it. I used it to extract models from Little Witch Nobeta and then did absolutely fuck all with those models. Then I remember some games just didn't work at all.
Reminder that Decompilation does not preserve code structure.It doesn't excuse anything retarded but at the same time any output isn't necessarily representative of the actual code base.
Unity decompiler is just C# decompiler,Anon.There are a few of them,I know DNSpy and ILSpy work well for unity games.
You need to find Assembly-CSharp.dll in the game files and feed it to the decomp.
Assets are a bit harder but there are a few rippers if you look around.
>Reminder that Decompilation does not preserve code structure.
That's true for lower level languages but C# decompilation, especially for Unity, is pretty spot on. Maybe the syntax for something changes, as seen here from the conversion from JS to C# but the behavior and overall code architecture is still the same.
No, C# is not particularly well preserved because of compiler shenanigans, like converting switch statements to ifelse ifelse ifelse ifelse ifelse ifelse and pieces of C# that seem identical in function often get compiled in different ways. Local variables are often pushed to the top of functions and have their names mangled, as the scope doesn't really exist. Source: Dude trust me
There's the one called "asset studio" or something. I don't know. I don't remember them being particularly hard to find, and the one I've been using and free and happily extracts assets.
I don't know anything about how you're supposed to handle input in Unity, but I don't see anything wrong with that aside calling the same getcomponent thing many times.
Fucking finally. Turns out I didn't have to re-do anything, I just had to use a better glTF 2 exporter.
>a better glTF 2 exporter
The one in blender 2.93 instead of blender 2.80.
Yeah, the one in 2.80 is broken, especially animation exporting, I've reported multiple bugs against it. IIRC 2.82-2.83 is around where they finally fixed the bugs.
Holy shit I've underestimated error checking. Like putting checks on everything that check for invalid states, such as checking if some array data is allocated every time you try to add shit into it.
Some problems that come out of nowhere have been basic things like this created by some minor refactor, and there's no way I would have guessed that that was the problem, since I thought I didn't even touch it. But since there was an error check there, it just caught it automatically. I can then make it disappear on release mode, so all those checks won't interfere with performance no matter how excessive they are.
You can even keep these in the release build and it won't make a difference 99% of the time. This ricer obsession with ripping out every safety feature and backup plan to carve out a usually imperceptible performance improvement is something like an occupational disease.
A check is easy to add so you can detect the problem, but handling a bug "gracefully" usually just adds too much friction and makes it harder to make progress. It's not supposed to happen to begin with so the program isn't going to continue running correctly, you might as well shut it down.
I didn't say otherwise. My point was that fags often just let invalid input wreak havoc all over the program. Most commonly through memory corruption but it can happen in memory-safe languages too (just more rarely).
Wait, they don't teach people to do this anymore? No wonder the industry looks like it does.
>implying anyone has taught me anything
>implying I would listen to anything that modern developers say in the first place
I bet they don't even teach you how to do function overloading in C.
Most programmers don't go through formal training but are simply self-taught. Even if they're taught, the lesson gets ignored because muh speed is just so enticing. The 1% performance increase is measurable by anyone even if it's unimportant; the time you saved not hunting down retarded errors isn't.
Presumably you obtained your knowledge from things such as books, online resources or reading other peoples code. As in various resources that allow one person to teach others about things.
But what do I know, maybe you're all wizards that conjured up the knowledge out of thin air. Personally I started as a kid with some dusty C book.
Are you trying to free() stack memory?
>Are you trying to free() stack memory?
I made an overloaded free() that uses a struct-specific free function that frees all of the relevant data from the struct. I had it approximately long enough to post that screenshot until I realized it's a stupid idea because if the struct by itself is allocated for some reason, you can't use free() to free it.
Reading the odd book and piecing together info from manuals and the net hardly counts as formal training.
I can see how my original post could be interpreted that way but thats not what I meant. If your manual, C for retards book, teacher, online guide or other resource for example does not tell you that you should do something so fundamental as error checking return values and other things you can safely assume it's some nu-soy shit that belongs in the garbage.
There's different kinds of error checking though. There's checking for errors, and checking for bugs.
For example when you want to add something into the end of an array, it's fairly clear that you should check if there's enough space left in it. However, it's not immediately obvious that you should check whether the provided array data is allocated in the first place. The first one is expected behavior and can either produce a soft error or do something else, but the second one is a bug in your program and never supposed to happen.
took me like an hour to figure this code out.
You're using "_Generic(x)" right?
Somehow I just found out that exists.
_Generic is one part of it, but it tends to break if you have variable number of arguments. So I use a much more esoteric trick that allows me to check specific variable arguments, for example check if there's no 4th argument.
Pic related, there's 2 functions where the second argument is an integer (_data where it's the data length, and _int where it's the integer you want to add). At the bottom of the macro I check if the third argument is NO_ARG (i.e. there's no argument) in which case it goes to _int, otherwise it goes to _data.
Here's how the variable arguments stuff is implemented in case anyone wants to know. The way it works is pretty simple, but hard to explain.
ARG_X calls _ARG_X with the same arguments, but also adds a number of NO_ARG values after it. Take for instance ARG_1:
ARG_1() -> _ARG1(NO_ARG). _ARG1 returns the first argument given to it, and thus returns NO_ARG.
ARG_1(x) -> _ARG1(x, NO_ARG). _ARG1 returns the first argument given to it, and thus returns 'x'.
The NO_ARG struct is just so _Generic can capture it.
This is minor shit, but still helpful if you're using Unity on lignux.
If you want to download specific older Unity builds using UnityHub, you have to do it through unityhub:// links on the download archive. By default, the appimage does not support this. It seems you have to maks a custom .desktop file and fuck around with xdg-mime to get this working. First you make ~/.local/share/applications/unityhub-handler.desktop with the following contents:
MimeType=x-scheme-handler/unityhub;And then you run:
xdg-mime default unityhub-handler.desktop x-scheme-handler/unityhubIf you're unfortunate enough to be using Unity, I hope this helps. I couldn't find anything on this last year and the only post I found with an actual answer was made last month. It's the sort of thing you wouldn't think of unless you knew your xdg shit.
Isn't it enough if you just run your unityhub with the unityhub:// url passed to it? Like ~/wherever/you/put/UnityHub.AppImage unityhub://whatever? Yes, it requires manual copy-paste but if you only need this occasionally, it might be easier to do it manually than to fuck with xdg (that never works anyway).
Also, UnityHub, WTF, last time I tried to use Unity it was just some tar.gz that you downloaded from the webpage and unpacked it. No appimage fuckery either.
>just some tar.gz
I fucking wish. Before the appimage, I remember it having some gay installer that bitched and moaned about my distro not having its libraries compiled exactly the way it wanted.
I wish my fucking lizard brain would allow me to focus and learn to code so I can do this shit. God damn, I really should be so miserable at studying, but today is going to be the fucking day I start even if it's past 10pm. I'm going to finally read the fucking purple book instead of pretending I have for the past four years. I'll get back to you fags when I have questions.
I know how you feel, brother. I haven't coded in months, and I really want to actually start coding more. I'll start coding more when I get the chance.
Remember Jeb Bush's famous words, slow and steady wins the race.
Force yourself to work on stuff daily (even if it's really basic) and eventually you'll start learning. Make a hello word right now and something stupid tomorrow, then keep going day after day.
My ultimate goal is to make something in EDuke32, so I don't think I'll need an excessive amount of ability, but I at least want to be able to understand how things work so I need to at least be literate. I should really make the switch to Linux at some point. I need to buy a Thinkpad.
If you're forcing yourself, you're not going slow and steady. The important part, I think, is to make whatever you're working on easy enough that you don't have to force yourself.
Some days you just want to be a piece of shit and you have to force yourself to do the simplest of tasks.
AppImages are just glorified .tar.gz archives anyway, the only difference is you can simply launch them without extraction and they're read only.
You can experiment with linux in a vm, it's what I did for a while before I actually started booting my machine into it.
I've done some Hello Worlds just now in C with Classes. Are there any good easy-modo programs that would carry over for /agdg/ projects?
Clone an ATARI game, like asteroids.
With asteroids you will, at a minimum, learn a bit of graphics programming, input handling, how a game loop works, and simple physics (momentum and collision detection), but you can expand it into a full game with sounds, music, a start menu, pause menu, and whatever else. While you could do it entirely from scratch, I recommend using libraries like OpenGL and GLFW to start out.
Don't worry about doing any complicated design pattern. Just think about what the data does and program the simplest thing to accomplish your goal. Sometimes you'll figure out the simplest thing after you build it out more and so you'll have to go back.
It will also offer a good test bed for learning project organization and planning. An ATARI game is simple enough that it won't be a second job trying to keep it organized, but complex enough that putting it all in a single file is a bad idea. You will learn a lot throughout the process and need to go back and refactor things, which will be a good experience. You will also need to create a plan (or else waste a lot of time floundering around wondering what to do) which will help you with project planning and decomposing a complex project into it's constituent parts.
>straight from "hello world" into making a videogame
I think figuring out how to set up SDL would be a more reasonable first step. Making rectangles move around would be a good second step.
It's easier to start out with just text. You can make a lot of cool games with just ASCII, or even better whatever "high ASCII" characters your platform has (DOS has shitloads of games like this). In the 8-bit days, it was a common feature that you could redefine any single character you wanted at runtime, and this was handy for making "sprites" out of text. You can see in this Boulder Dash clone he redefines characters 243-255 at the beginning of his program, and the sprites are simply blocks of 4 characters each. This way it's piss-easy to draw and also do collision detection.
I took "some Hello Worlds" to mean several small projects, not just "Hello World". If my assumption was wrong and they only have "Hello World" under their belt then they should first learn about for and while loops, arrays, strings, recursion, pointers, malloc and free, dividing a program into functions, header files, downloading and using libraries, makefiles, macros, debugging tools and all the other core features of their language and developing in their language.
But after all that, setting up OpenGL isn't that hard and the tutorials out there on how to do it are very good. Part of cloning an Atari game is learning how to draw a rectangle (or line, etc.) and moving it around. If they're making a game that just means they have a path beyond step 2.
Grid-based collision is a really good place to start when learning how to do collision. If you want to make an ASCII game then you'll probably need ncurses or something similar.
>makefiles and debug tools
>how to make beginners lose interest in programming in one simple step
I don't think these are among the first things to learn either.
I appreciate the advice, but I'm coming back after losing motivation. So I've got programming experience from reading books and practice, although I'm admittedly utterly unable to logically process recursion and how the hell it works, even after being explained in detail.
Well, to understand recursion, first you have to understand recursion...
Anyway, take a simple example, merge sort. How do you merge two sorted arrays? You start iterating through both A and B, if the item at A is smaller take that, else take the item from B.
So we have an unsorted vector, how to sort it? If we would have a function that could sort smaller arrays, we could just split the array into two, sort them, and merge the result. How do we sort the smaller arrays? With the exact same algorithm! Split them in half, sort each part, and merge. Sooner or later you'll reach the point where your sorting algorithm is called with a zero or one size array, and well, they're trivially sorted, so you're done.
You can also start thinking from the other direction, how do you sort 0/1 length array? You don't sort, they're already sorted. How do you sort a larger array? Split them into two, sort the two halves then merge. Because you halve the size of the array in each step, you'll eventually reach the 0 or 1 size case.
Quicksort is also simple to understand after you grasp recursion (IMHO the principle is even simpler than bubble sort, which is somewhy the first algorithm presented in almost every programming book)
Recursion is also useful with tree-like structures.
Just keep in mind that unless you're using a functional language, the limit of how deep you can go with recursion can be pretty low, and in C/C++ if you exhaust this space your program will just crash.
Makefiles and debugging weren't among the first things I listed, and they don't need to be learned in any great depth as a beginner to get the advantages of them. A beginner only really needs a two line makefile when starting out, and they need to know how to compile in debug mode and use breakpoints.
Good news is you don't need recursion for most games, especially if you don't do back-end sutff. Bad news is that recursion is really dang useful and comes up in a lot of common algorithms (like tree traversal and quicksort). If you want I can take my own crack at explaining it.
If you're coming back after loosing motivation then I recommend keeping the projects small so that you finish them before too long. Things like a rock-paper-scissors game or tic-tack-toe are easy to do and can be completed pretty quickly. Disregard my "clone an atari game" advice. It worked very well for me when I was learning c++, but I wasn't starting demotivated. I still believe it's worth coming back to in the future.
A debugger is overkill when you're just calling a few functions, and you don't need a build system when all your code fits into one or two files. It's fine if you're reading some book or tutorial and it shows you everything, but otherwise they just add extra mental overhead and work that needs to be done in order to do anything.
Okay, I'm getting the general idea. So if I wanted, in the asteroids example, to subdivide an asteroid repeatedly into smaller pieces, all I have to do is create the subdivide function, and for each subdivide, call the function again until they're all tiny pieces? A bit of a clumsy example, but hopefully you'll see my logic.
I have never ever messed with a makefile (since most of my compilations have just been through invoking GCC on the terminal). I suppose I ought to learn the syntax, which shouldn't be too hard if it's Ganoo/Unix. With the practice games, I've already started on the Asteroids game with the twist of it being a cute girl harvesting big resources while also fighting space cops, rival miners, and space pirates, and then using loot to upgrade the cute girl's cute ship and stuff. It'd be a pretty fun concept, but if I feel it's a little too much for me, I'll try and go smaller with RPS or tic-tack-toe.
gcc -o output main.c
There's your first makefile. Takes in the main.c file and outputs an executable named "output". Type "make" into the terminal to run it. For more information:
I wouldn't use recursion for sub-dividing an asteroid. I would have a function that records the size and position of an asteroid, deletes it, and then spawns two (or however many) smaller asteroids in it's place. Recursion is used more like a fancy loop. If you need an algorithm to be able to handle a list/group of things in a certain way then recursion may be the way to do it.
The subdivision present in merge sort is simply an aspect of merge sort and not inherent to recursion, and cannot be applied broadly to sub-dividing asteroids in a game.
As for your version of asteroids, what you describe is ||significantly|| more difficult than just an asteroid's clone. Way more moving parts and things you have to balance. I would recommend going with the simpler asteroids first so you better understand the risks and challenges of cute-girl asteroids. And when you go with your version, don't be afraid to move over to an engine or use libraries to handle more stuff.
Best of luck with RPS and tic-tack-toe.
Everything you can do with iteration, you can do it with recursion and vice versa. It's just that sometimes one method is much simpler than the other.
For asteroid sub-dividing, it's indeed more simple to create a bunch of small asteroids in a loop that doing a split into two and recurse (especially if you want to subdivide them into non power-of-two pieces, not counting that the simple iteration will be likely faster as you don't create temporary asteroids that you destroy moments later).
The distinction when it's worth to use recursion and when not can be quite subtle, and I don't think I could give you any simple guidelines when to use what. Probably the best you can do is to first try to think of an iterative approach, and if it seems too complicated think if you could use some recursion.
Generally unless you need to process some kind of recursive structure (trees, file system, etc) you probably don't need recursion.
Two words Anon.
Search a unit testing framework for your language and read the tutorial.
Well I made some progress today, I made basic scripts for adding new weapons, refactored the ore scripts so that it can support 3 different ore types, made the refinery a bit more fancier to operate with sound and particle effects and the light laser gun is made a bit more complete in the sense it visually behaves like a gun now.
>win98 like window borders
>lutris next to godot
>wrong video aspect ratio
Someone tell me what the hell is going on
unit testing is cringe, only use it if you are working with other retards
based on that attitude, I'd guess you've never worked on any reasonably good sized code of your own. once you reach ~10kloc, you can't keep it all in your head. Probably more like 5k in your case actually.
Unit-testing is a Godsend, actually.
Language Files Lines Blank Comment Code
Total 64 9100 403 150 8547
Unit testing is for pansies. Just write code that works and you don't need to test it.
Just don't ever change the slightest thing about the code you managed to hack together to sort of work...
unless you're refactoring multiple parts of your system/project, you don't need to write up basic unit testing, the other types of testing are way more valuable imo
>win98 like window borders
No idea why, on other themes it reverts to Ubuntu Mate icon probably because the one I'm using is from some themes I have manually installed.
>lutris next to godot
I had to start godot via lutris because somehow godot per default tries to use discrete GPU which causes my computer to crash to the login screen
>wrong video aspect ratio
I just picked one of the smaller resolution from arandr and entered it into OBS as OBS for some reason has some odd and limited resolution available to choose from, what a piece of shit.
>OBS for some reason has some odd and limited resolution available to choose from
You know, it's an editable combo box, you just type in whatever you want. Those predefined values are for retards who can't remember two numbers. I personally recorded videos with completely weird resolutions (a random portion of my screen) with OBS, it works without problems.
Unit testing is like version control, if you never used it, you're completely fine with it, then you get used to it and can't go back. Have fun with changing one piece of code breaking something else in a completely unexpected way that you didn't manually test after the change (since you didn't expect it can break), so you only find it out much later, perhaps after your users start complaining that your game is shit.
>unit testing over way better buzzword testing like integration testing & system testing that literally tests the relationship between different things instead of focusing on a singular gay 'assert('addsum(5, 3) = 8') -'tier bullshit
version control is fucking goat, period but that's not the point - unit testing by itself isn't that great
>fill in pixels in the simplest loop you could think of
>for (x<width) imagedata[x] = colorpixel;
>hmm what if I use SIMD registers
>becomes convoluted as fuck
>there's no way this will be faster
>it's 4 times faster
>ok but the compiler will optimize the simple loop if I compile on release mode
>SIMD version is now 10 times faster
I guess the compiler doesn't use SIMD in optimizations?
Why are you reimplementing basic software rendering from scratch?
Because drawing certain things in the GPU is annoying as hell.
Fucking retard, your "clever" SIMD solution is still 100x slower than delegating to the GPU.
Here's a trick for being motivated: don't do things you don't want to do.
This program I made now works 2-3 times more efficiently than it used to because of some optimizations I made to my software rendering functions (pic is roughly the maximum utilization when I'm moving my cursor around and it redraws everything at 144hz), and I also gained a much better understanding of SIMD and other things while doing it. But more important than the speed, I most likely would have never made this program at all had I forced myself to use the GPU just because "it's more powerful", or because niggers start crying that I'm not doing something the Correct Way™. Same thing with my game projects, I always start out with software rendering because it's much easier and more interesting to set up and gives more insight into my program and I hate OpenGL. If the game doesn't scale up or if I make a program like this, then I won't bother to move to GPU at all because this is less annoying.
There's a lot of things I do that people seem to get irrationally angry about even though it has nothing to do with them, and I'm much happier when I don't give a fuck about what anyone else says. I'll do whatever "incorrect" things I want to, I'll #include my code straight from .c files, if it works and I'm more comfortable with it, then I'm going to do it so I can continue working on stuff without feeling like I'm sitting on a vise.
You should try Vulkan if you haven't, its a bit more verbose but that's because you're doing actual programming and not "copy paste the 200 lines of state setting boilerplate from the guide, don't think about what it does because khronos certainly didn't".
>here's a few tricks for being motivated
>never try to improve yourself
>never get out of your comfort zone
>never wonder how people much smarter than you tackled a problem through time
>never strive to get a better understanding of what's going on behind the scenes
>always get defensive and spew strawmen when criticized
In the off chance you decide to get off your lazy NEET ass and try to get your life back on track, hardware rendering beats software rendering not simply because of speed and efficiency considerations, but because it's a good abstraction that helps you write sane code (no dependencies between rendered pixels, for example) and helps you understand what you're actually doing when you draw some text on screen.
obviously improving and learning new things are good, but if anon is doing it for fun, i don't see why he needs to force himself to do something he doesn't enjoy
The problem is the attitude, not the end result: if anon had just done it for the lulz/to experiment with compiler optimizations/to get a quick and dirty prototype running it would be one thing, but >>68303 makes it clear that's not the case: he's committed to doing twice the work for half the results rather than learn a new thing.
>twice the work for half the results
Is there even any point to posting here if people don't read the post before replying?
Too right, people only exist to make you suffer.
Progress was a pretty slow one this few weeks, getting caught up in other things, working on myself mentally, emotionally, and artistically.
No screenshots today, nothing really worth showing.
'Progress Report : Uncommon Time - Retuned'
--Added a new tier of weaponry for act 2, when you reach Tenuto Spring.
--as a result of the above, I had to update meirin's strawberry barrage to include another elemental ability.
--Strawberry barrage now only plays it's animations once.
----Did some status-based rebalancing.
--Buffed Trionfalles and Tuttitrionfalles, they now restore all status effects- this also includes the normally-insidious virus status affliction. As a result of this, I have also drastically increased their costs.
--Buffed Immunodeficiency - it now has a 35% chance to cause virus.
--Anti-affliction shields no longer protect against virus.
--Decided against restricting access to Spiritoso Peak in act 2: as such I have added post-split dialogue for if you enter that area when playing as Teagan. The entirety of the zone itself will not be fully accessible until you complete side-content for act 3- by the point you are able to access this area, you are fully on the road to accessing the encore arc and the best end.
I wish that my computer could run OBS and my game at the same time at above-slide-show frame rates. The game runs better in person.
Anyway, I figure since this is my first time showing off the game I should offer a brief overview. It's a first person melee game. You fight waves of enemies in an arena. The hexagon in the middle of the screen tells you when that side of you is being targeted by an enemy, and when an enemy is about to attack. You can block in order to mitigate damage, and if you block right before an attack lands, you parry it and the enemy is stunned for a bit. Combat will get more depth as time goes on.
Recently, I did some experimentation with boids to handle groups of AI's. The boids part of my code worked out, but in the testing phase I found out that Godot does not like it when you move_and_slide a bunch of kinematic bodies at once. I'll probably end up using less intensive movement code and low-cohesion, high-separation boids for the majority of enemies. move_and_slide is just for the enemies around the player.
I will be doing a bunch of back-end stuff next, so it'll be a bit before I have something new to show.
>I wish that my computer could run OBS and my game at the same time at above-slide-show frame rates
Are you using game capture in OBS? It's more efficient than desktop/window capture.
Didn't realize it was an option. I will look into it.
Is cc0textures dead? I haven't visited in a while and it seems to be gone.
Can anyone give us an informed opinion on the upcoming Godot 4? I get the feeling that the faggot gendered devs have high expectations that it will become competitive with commercial engines, as opposed to Godot 3 which is basically 2d only in practice. Is there anything at all to get excited about?
I'm personally very excited about waiting for Godot 5 which will totally make it great unlike all the other updates that were supposed to make it great.
Here are some of the bigger improvements 4.0 has/is going to have over the 3.x releases.
>Improved rendering for 3d. Global illumination, volumetric fog, occlusion culling, room/portal culling, shadows that "just work" etc.
>There's also 2d rending improvements, but 3d is the big one.
>Improvements to the editor and 3d asset pipeline.
>Various optimization improvements.
>Godot Physics is becoming the default, instead of Bullet. This is a brand new physics engine, not the old Godot Physics.
>Improvements are being made to GDScript both in performance and features. Specifically what I've seen is better handling of typed variables.
>Improved AI navigation tools.
>Other stuff I'm probably missing.
I don't know you so I don't know if you consider any of this worth getting excited over. Personally I'm looking forward to it. If nothing else I'm just glad the default 3d blue is going to be gone.
What probably won't excite you is that it's Vulkan only in order to get 4.0 out sooner. So much is changing on the 3d rendering side that at their current team size it's not feasible to do everything in every renderer for this release. From what I've read 4.1 will add the other renderers back in, which is just classic Godot. More waiting.
All in all 4.0 is going to be great for people who already use Godot, especially on the 3d side, and are fine with Vulkan only; i.e. me. I don't think it's going to cause any kind of significant migration from Unity or Unreal.
Honestly even if they could fully dominate the market for 2D engines that'd be good.
I managed to get rich irl
where do I hire modlers and musicians for my project?
There are a bunch of online services that you can use to find musicians and artists for hire if you just use a search engine. Failing that, if you want to find artists you need to go to where they congregate and ask them there. Artstation is one of those places, and it has recruitment tools.
Twitter, pixiv, DA are basic obvious places to start
Backend stuff finished sooner than expected, so I was able to work on some shaders and particles.