Tuesday, 20 December 2016

Adventopolis 1.#INF - I am bored

So, that's it. The experiment is over. I don't plan to do any more entries of this. What is done is done. It helped me a bit at some moments to work on two things, the 2d software rendered framework that will be used for 2d PC/handheld games in the future (and I tested a bit how practical it is with the unfinished Ludum Dare entry and know what works and what to change/improve) and some more work on the CPC wolfenstein, mainly the editor and the zooming sprites. And that's good. But it was kinda forced to have to work each evening just to post an update. And I got tired and I proved what I wanted to.

The last few days before xmas are coming. At 22 I'll be flying back to Greece for holidays. Then I'll come back next year with new plans and dreams. I am already thinking some new years resolutions or better call them new months resolution and making a plan to allow me finish early enough some of the things I want to proceed. For example, if I procrastinate too much with things, if I see myself still fighting with the technical things of the wolfenstein engine in August, then it get go September, October and I will be like, fuck it, I am finishing this next year. But maybe I can set up monthly goals and see how it progress, or checkpoints like moments where there will be stop in flow, like for example eastern in April where I might travel back to Greece again as usually (I always go three times on Xmas, Eastern and some period in the Summer to see friends and family) and will cut the creative flow for 1-2 weeks and then coming back I need time to rewind. So, I could have a plan of what I'd wish to finish by that time. And maybe watch out every week or month for what I wanted to finish and what happened.

Or maybe focus more on setting me in the mentality of procrastinating less. I believe 2017 will be the year I should break this and get into new stuff that need the focus, need the change in mentality to achieve what I want.

Anyway, merry xmas and a happy new year if I don't see you in another post here!

Saturday, 17 December 2016

Adventopolis #17 - the zoom must go on

I didn't work all day this Saturday. I went out to the city and then out again to meet a friend. And that's ok, didn't plan to bruteforce this weekend anyway. I only came back in the evening, rested for a while and then decided I have to code something just to write this (slight motivator to code at least one hour per day, interesting, but not something I would like to do in such fashion all the time).

I decided to test some more on the zooming on CPC wolfenstein and see how much it takes to sort of position a sprite and zoom according to the distance to the player. But of course I made a bad mockery with 1D distances just to see it. I will need real sqrt on CPC unless I can think of another way, but now it's doing a fake thing just to see and imagine how it would feel like. Also, no real positiong from 3D to 2D yet and no clipping at all. I even made a video about it.

Other than that, I am thinking tomorrow again of a youtube video I wanted to do criticising level design of a specific FPS and I might try to bruteforce it in the morning so that I don't end up at night and feel like doing nothing. And then I was playing again with an idea I have, which I don't remember if I mentioned yesterday and I am too lazy to check, for speed coding and maybe some youtube vid/timelapse. Also another way to maybe motivate me to try specific stuff I postpone. Select something you wanted to code and try to code it fast, either something you have coded before or a new effect you never made before. It's like the speedmapping on Doom where they try to make a map in 30 minutes for example (I might try to do one of these too and maybe timelapse it :).

Anyway I don't know how it will be tomorrow and if I'll end doing something. Then I'll have something like 4 days or less inside the weekend. Maybe my last wish was to release something for the Sam? Not sure now though, old lousy assembly code which I could fix or maybe I'll release something as is. I even have to bother switching on my Sam and see how I will transfer the thing I'll be doing to check if it works.

Friday, 16 December 2016

Adventopolis #16 - time before the second fail

Ok, it's 15 minutes before midnight, I was about to miss the next post. Yesterdays post was forgotten, it was over 2:00 after midnight but it's ok, I had to do something else.

Little things now, it's Friday and I just finished the unification of the Wolfenstein FPS and also tried sort of press Space to fire projectile zooming blue fireball. It's blue for now because I am trying on red walls texture. Of course it just zooms at the center, no real positioning yet.

I have another idea for speed coding. Might try it at some point.

p.s. I already got bored of this, but I am gonna continue it till the end..
p.p.s. I cheated and change the date of yesterday's post. I just wanted them to line up every day in the list.

Thursday, 15 December 2016

Adventopolis #15.5 - First Fail

Ok, I was very busy with something else I had to do outside of coding, then I checked the time and I am sleepy as fuck too.

Wednesday, 14 December 2016

Adventopolis #14 - and the bat is in!

Things going well, although I am coding for 1+ hour, my new plan is waste time before hand and code something at ten. Hehe,. it short of works, but might change strategy in the future if I want to do more. Or maybe it's an ok strategy to motivate me to work on something instead of nothing. This night's task was to transfer the two frame of the bat enemy sprite (no joke about Batman Group :) from sigh, see how it looks (it kinda blends weirdly with black or dark blue, sigh's sprite was black, I changed it to blue, maybe try some gray or something). I also added a sprite struct in the CPC code, so that I have different sprites, both the fireball and bat frames and select which to render. It used to be a function that read a single global spr array in the past, just for testing. Now it's ready to render many different sprites of different width/height. I am still rendering in the center, so I need to next solve real x,y,z position to x,y and zoom on the screen. And maybe optimize the speed.

I am getting good with screenshots in these posts (although don't expect it daily). But when I finish a proper move around level, meet static bats flapping their wings in real 3d and shoot fireballs, maybe clip and of course zoom rewritten in assembly for fast speed, it will be proper for a youtube progress preview. That's all I want to do (this year? Don't know). Then I am at the next stage of the engine/game. Where I have to go back to solve, raycaster problems/speed improvements, and then rewrite this big thing in assembly. And call it a day. And figure out where to go next (I might have to check my remaining memory, I hit something again by adding all three sprites but I am not sure). Then what remains is the texture editor/special effects with column offsets (torch animations, sliding doors (that will need also transparency)). It will at some point feel more complete and ready to start coding the gameplay. Lot's of small and bigger things I hope to reach a point where it doesn't feel scary.

Tuesday, 13 December 2016

Adventopolis #13 - finally a screenshot

I did more than I thought, most of it was easy, finishing the touches on the CPC sprite editor for wolfenstein, but also the save/load to binary and C/asm source (taken from the same on map). I felt I shouldn't do a 10 minutes work looking 30 minutes at the ceiling for this, so I coded fast and it oh went so well, I even painted a simple fireball and tested it on the lousy slow C zoom routine on the engine. Here is a screenshot.

Little fireball is coming on me, I attack with my dagger,.. or nothing like this happens anyway. It's just a zoom animation from 1x to 4x. At 1x it's ok at 3x/4x it slow down everything. Of course that's the routine I have to write in assembly and I know now how (and it will be quite faster and allow more zooming sprites at the same time).

So, maybe tomorrow I can continue with some other things on the same project. I was initially thinking to transfer also the bat two sprite animation I got from our graphician, but maybe it's not necessary now. Unless I want to animate two frames and place it somewhere on the map and let me approach it. Right now the zoom routine can take x,y screen position and zooming factor. It might even do some clipping iirc, not sure. But what it does not do is take real x,y,z, check visibility with player camera and transform to x,y and zoom, maybe even clip with walls. I'd like to think how to do it efficiently or at least and easy brute force just to see it, just to move near a sprite in the real 3d world. Or alternatively I could optimize the sprite routine with the assembly I have in mind. Or make the player shoot those fireballs by pressing fire, preferably in the UnifiedFPS version I still haven't finished unifying.

I hope tomorrow I am similarly motivated.

Monday, 12 December 2016

Adventopolis #12 - The color of coffee

Title doesn't make sense. I just wanted to name something like that. Like the color of money or the color of magic. Procrastination is the color of coffee.

So, it was time to not work further with my Ludum Dare entry. I only added some image loading but never bothered drawing my Pallew Pallew and Zardoz enemies. I thought I should rest and that was enough to port my wolfenstein on PC and start doing something with my Pallewsoft framework so that I see what I like about it and what I can change. Also discovered some issues with my wolf engine in highres that I didn't think about before. There is warping even after fishbowl correction (taken from Permadi tutorial) and I have to think about that, someone told me something on Pouet about it.

I kinda started playing with my other dream, to make some better youtube videos for some game rants. Just got Bandicam and Audacity trying various ways on how I will make those videos. Should I capture mic and game sound separately so that I combine together? Should I make little scripts of what I will say, play parts of the game separately and later on add the voice? I am playing with that. One critic I wanted to do on Duke Nukem World Tour levels, that's better explained by showing stuff and adding voice than ranting on gaming reviews, I could start doing small snipsets of videos (but don't think I will be close to releasing the video this year). I almost tried it but I haven't found a confident way to do it. I assume it's gonna be a pain to express myself through some more carefully made youtube videos.

Not sure how to continue this anymore. The plan is to keep pushing and motivate me to work on few stuff for the rest of the days I will write something on the blog. I could continue with the CPC wolf editor which is going nicely or do some fragments and prepare script of the vid I want to make. Or maybe do the Sam Coupe mini intro thing, just to not break the promise of this year.

I'll have to break the habits and change strategy on how I work with things if I want next year to successfully work on some bigger new projects. Maybe this is a test here..

Sunday, 11 December 2016

Adventopolis #11 - Close but no Jam

Woke up later today, started working at moment on my Ludum Dare entry, which as I see won't make it today. And I am not even sure I want to spend time tomorrow with the Jam. Unless maybe late. I did solve most of the raycaster bugs, have some proper controls, right now planning to generate or load some textures, start building the door rooms, need to still make a loader for few images, like the crappy enemies I was planning to draw with MS Paint and record lousy sounds and call it a day. The enemies won't even move, there will be no enemies, just the idea of many many doors but one is real. Just a jokeprod. But I am not even close. At least, I wanted to port/rewrite the raycast wolfenstein engine in a modern environment and try some more stuff in the future (I will push that in a repo and work it in the future). It might also help for rechecking some stuff I was struggling with on CPC.

So even if no ludum dare (or maybe the Jam? Still pondering about it..) at least I worked more than usually and it was fun sometimes except from the bugs, and I worked that on my new Pallew Pallew soft framework and it can grow in the future for other game projects (but hopefully no 2 day Ludum Dare, I wanna take my time, lot's of lousy code not written the way I wanted).

The idea is whether I'll finish this tomorrow or rather ditch it and spend tomorrow on the other projects I left back. Continue with the CPC wolfenstein editor that is going nicer and slower, or maybe give 2-3 hours in making my first fragments of a little youtube video on a specific FPS level design rant I want to have. I need to start my youtube dreams too, at least see how much it takes to complete a small part of one vid.

Saturday, 10 December 2016

Adventopolis #10 - much but not much

So, I decided to take a chance on the latest Ludum Dare, theme one room. I was thinking to do some stupid thing with the raycaster engine, of course on PC with SDL, rewriting it from scratch. Half of my day was lost on doing other things (I see again how procrastination works, wanting to check something on the internet for 5 minutes, ending two hours, then feeling the dread, the more it goes the more you know you are never gonna start). And yet I started at 3:00pm and sort of motivated by listening to some 8bit tunes, hehe.

It's going good, just I don't have anything yet, almost ported my code but it crashes with bugs in the raycaster. I worked more than usual (till I got hungry at 9:00pm) but too much without much to show. I was hoping to have the raycaster movement so that I can program some lousy gameplay. Hopefully tomorrow before lunch.

Yet I am thinking and do wish, if I do something to finish it tomorrow and not go for the Jam. I could use my Monday (which I have a day off) to focus on the other projects, continue the CPC wolf editor which goes nicely, maybe start working on some other stuff. So, it's either debugging the wolf fast and then start creating things tomorrow all day or nothing. But I wanted to rewrite the raycaster engine on modern PC anyway, just to test some new stuff at some point. Although because of LD I code things fast and not elegant. Maybe I can finish something and improve structure in the future.

p.s. I already got bored writing these series of advent blogs, especially when I don't have much good news or some teaser (it sometimes feels awkward), but I plan to do it till 21 and see what happens. Yet, I see just by posting everyday to get more visitors, which is interesting.

Friday, 9 December 2016

Adventopolis #9 - Freeday

Nuff said.. it's only Freitag when I want to have a free time. Then again I always push it now for an hour or half. I added the palette displayer and selector which can be used for all CPC editor modes. I do the bunch of functions in such a way that can be easily used for the rest, but for now I want to finish the basic sprite editor functionality and try to paint few easy sprites for the future.

Tomorrow is Ludum Dare day and while I might be motivated or not to do something depending on the theme and whether I want to get into, I am seeing now how nice programming there is with the editor seeing things growing up. I only need to think of a good simple megastructure to save the whole data and maybe the logic will be that each level will have unique palette, wall textures/columns and sprites in a pack. So one level will have different color scheme than the next, but also a compact way to pack the data for a level and maybe each time a level is changed to extract data from the extra 128k memory or cartidge. The 64k plain CPC will be harder unless there is space by the end of the code for those data or compress them or find a non basic loader to load them from disk later on. I can fit some data at the moment but maybe when it grows there will be problem unless you are on 128k where I still have 48k free to use (I use 16k for texture/sprite data, 32k for double buffered vram, 16k for unroll codes and 16k for code).

So, I guess I might try to code this inbetween because it could be great if I would use this weekend to push it and it's motivating enough right now it's building. A more complete editor will motivate me to paint some test stuff and see the levels showing up. Then it might motivate me to optimize and finish the sprite zoomer and I only need transparent textures for the door animation. Then it's just to fix the bugs in the raycaster and take the big effort of porting some stuff to assembly (that could improve a lot the speed and save some memory). At some point the whole project will be at a form that I guess it might become more fun to complete and actually start building the main gameplay code.

p.s. As I side project I am thinking of my youtube vid ideas. But anyway, I am not gonna force all three of them, I just had the inspiration recently, after watching some other youtube vids. It will go away soon..

Thursday, 8 December 2016

Adventopolis #8 - the editor

Yes, still some CPC essential coding. Or of course not CPC but PC SDL code for the editors of my Wolfenstein RPG/FPS games. I already had an editor I showed before to draw the level map and select textures. But I was inspired to start carefully building the whole infrastructure for the rest, sprite drawing, texture with column editing and weapon drawing. Well, I am still at 2% of course, but I started cleaning up code and making some functions to be used from all. These are mainly to draw a grid, returning from mouse to grid and back, so I'll have big cells where I will draw but they will be translated forth and back to real mouse pos and sprite pixel pos.

Lot's of things have to be done, but these editors are easy to do, nothing complex, just some tedious work. And I need to thing of the structs and what I will save in files. Right now for example, when the editor starts, map1.bin is loaded with 256 values for a 16*16 bitmap. And I draw and with mousewheel switch between 4 textures. But they are default textures, I cannot edit them or load new. F6 saves back to disk, both the map1.bin and extracts .asm files with the byte definitions. It's so simplistic. I added switching with F1-F4 between the four editors. The others are just displaying an empty grid and in the sprite I can draw random colors, although not from CPC palette.

I should also have a palette editor, as sprites, textures, floor/ceiling and weapons will use the same palette. So, maybe it will be a full struct of a level, combining struct of a map, many structs of textures, sprites, etc, appearing only on that level. For a different level I will use different set of data, different palette and drawing graphics especially for that palette. On the weapon side, I already have an old code converting weapon rendering to very fast unrolled assembly. For the textures, it will be a list of 256*32 pixels, with 256 columns I can edit and then I have to think of a nice way to let me select which columns will make a texture, so that I can make the wall texture tricks or compressed textures I was discussing before. Lot's of work here and there, easy stuff, but I will need continuous motivation and enough days to complete it.

So, yeah, I kinda managed to motivate me to continue with this project, even though I end up writing this earlier as I need to rest the last hour. I will see what I can do tomorrow, as there might be a pause in the weekend, depending whether I want to switch again to participate in the Ludum Dare contest. I might be inspired by the theme and try to do something (maybe a good opportunity to continue developing on of my PC frameworks and test it in a gamedev attempt) or maybe not. There are not enough days left, so I want to push as much development as possible. Maybe near the last week I will start thinking of the one/two projects before the end of the year. A small Sam Coupe release but especially a primary focus into start attempting my youtube project plans (won't manage to release a video, but will see how easy it is to make fragments of a proper careful video).

I was even thinking to start posting images in these posts (pretty boring with only text?) but I don't have something worth it most of the time. Maybe tomorrow if I finish the sprite editor and try to transfer the bat graphics? I also thought of making this editor to draw some more, like a projectile, to test with the slow for now zoom engine and fire button, if I can press and the hero throws projectile that travels and hits the wall (lot's of work to be done for this too). Babysteps..

Wednesday, 7 December 2016

Adventopolis #7 - back to CPC

I was flirting with this idea since yesterday. While I plan to continue working on the wolfenstein engine used for a dungeon crawler based RPG movement, I wondered whether it would be a good idea to work on a smaller side project which will be a pure FPS. Maybe some fun minigame run and gun with a spacey theme, that's what I have in mind right now. I am also thinking of another way to render the walls that saves memory and might restrict the textures a tiny bit. I have inspiration from an already existing old FPS, trying to avoid limitations by doing that.

An RPG game could take longer to design and a simpler in gameplay mechanics shooting wolfenstein clone would be a nice inbetween project I think. But even the RPG game, I am planning to not take too much and aim at something not very big. Another reason is, I am thinking of an entirely different way to render, without raycasting, that might though allow for non-orthogonal walls. But that would need more research and rewriting of the engine. This is something I definitely want to try in the future, but my plan now is to finally focus on hopefully release something the next year. So, to release at least one of the two games and move on to a new engine might motivate me to finish in time. It might also sound like I am simplifying in order to release something harshly instead of spending more time to make it really good. But I realize since it will be my first real game on CPC and I don't have much experience in gamedev, maybe it's good to start smaller, don't make the biggest RPG world in your first attempt, make something smaller that could be 9 levels for example, don't bother much with story, maybe add some gameplay elements you'd wish to have for the first installation, and maybe go for RPG part 2 with the new engine in the future.

Anyway, so what I did today is to grab my old CPC FPS engine and mainly clean it up and unify the 64k/128k project files into one. This is almost finish, I need to test tomorrow and set up the environment. This is something I've already done some time ago with my Wolfenstein RPG project framework, took some time to set up everything, 64k vs 128k use different banks for data and vram and others, however this time I had the RPG framework to compare, and the pure 64k FPS version (with the old red wall textures and no weapon) to compare and update. It's done, I just have to setup preprocessor and other options in Codeblocks project (such a pain in the ass, I am doing it tomorrow).

I am excited about this and the next thing I want to do is see how easy it is to alter the unroll codes of the wall rendering to fit my new purpose. And maybe design some textures, run again that game that inspired me. Meanwhile I have the unoptimized C sprite zooming code in the RPG project and a plan to rewrite it in assembly, based on pseudocode I already have in mind. I can pass this on the FPS project so that I can shoot projectiles :)

Still, I worked on this 2 hours before midnight. Imagine what would be possible if I was motivated to focus more on my work. Still haven't figured out how to solve the procrastination problem. But writing these posts at least motivate me to work on something for half an hour or more, just to have something to say. Maybe after the end of this advent post calenderblog (which might just end at 21, I will be travelling for holidays in 22) I am thinking of another format, a weekly round up of what is achieved. Not daily, so I can take it more easy and not push things just for the sake of it, but at least weekly or biweekly so that I might focus on a plan and motivate myself.

Tuesday, 6 December 2016

Adventopolis #6 - Mandelbrot

I am posting this a little earlier today. Better than chasing eleven and a half. I want to relax today for two hours before waking up for work. Anyway, I didn't have much plans for today, even though I got some inspiration while I was at work. That's how it happens. You have something in mind you want to try but you have to wait for the evening. Then, when you arrive, you feel the laziness. You are too tired and the day is over.

One of them was easy, it's just porting my old mandelbrot code and testing something I was curious of. Whether floats or doubles prove to be faster. It's something I've tried before but I always had to go through all code and replace float with double and then back. So I just made something I thought also for future tests of other floating point heavy code, just made a typedef of float into real, so I use real all over the code and I can switch this typedef double to float and back and test. In a specific zoom, VS2015 does 38fps with double and 27fps with float. I used to think in the past that floats are faster because they are smaller, but that's in hardware where software emulation of FPU is necessary. But I've heard something that VS does a runtime conversion with floats that degrades performance. Afterall double fits more closely the 80bit FPU register size. Meanwhile, in Codeblocks I get a constant 35fps no matter if float or double, I guess it handles it better. Now, I'll keep this typedef and try to use the real keyword for floats, because if I port code to GP2X it might pay instantly to switch to float from double without having to replace all over the code.

I also cleaned up some of the thread code, I commented it for now, because of problems with MinGW on windows not supporting std threads. I could look at other ways to use threads but I can't bother with that right now. I have at some point to read and think how to implement thread pools. And I still need to review the code so far and think if I want to do things better or different.

Meanwhile, I was thinking ahead of the projects I want to really focus on (this project framework is more like an exercise to daily do even some tiny coding work, just to flex motivational muscles and maybe provide a good codebase for the future). Like CPC wolfenstein gamedev, gamedev in general and my youtube video ideas. Everyone of them is something on a bigger scale and I want at some point to think of these projects, visualize and ask myself, in case I am able to provide the determination to focus on any of them. For example, CPC wolfenstein, started as a tech demo, but there is a small dream there, to make my first proper(?) CPC game (if you can think of Flappy UFO as a complete game). I don't want it to take 3 more years and I am pretty sure if I can focus, I can have something the next year. I could aim that for the CPC retrodev of next year. But still not sure how it will go, maybe it won't be a big game, maybe something to be fun for a while. I am even favoring the idea to make a side project, with the real time FPS (the RPG will still be dungeon crawler style).

So, anyway, I am diverging here. I have my attention focused on that fact, some of the bigger things that are not lousy demos, need strong determination and focus. You see so far, I code some random thing for 1-2 hours, then watch youtube and the night is over, and even in the weekends where I have more time somehow it just passes. I am ok with that, but I know I need to change strategy if I want to work on the bigger things. So, I will lay down each of the 3 goals I have now and meditate upon them. What I want to do. Why I want to do it. How long I imagine it would take. When do I plan to start. What do these projects mean to me.

Monday, 5 December 2016

Adventopolis #5 - The fail must go on

Wanted to rest today. Almost coded threads as a last half hour resort.

Man, threads are insane. Right now, the test I am doing behaves different than yesterday. I run the multithreaded plasma effect, it gets 600fps, it used to be around 1500 yesterday. I am sure I am on release mode. Clean and recompile. At some runs it gets 1500 for 3-4 seconds and then drops back to 600. At other runs just stick to 600. Then I quit VS and go run it from exe and stays at 1500 as it should. Then back at VS, recompile, stays at 600 in and outside. What's going on? Then I decide to try with MinGW on codeblocks and realize C++11 threads are not supported. Shit.. there are some workarounds maybe but not something I can test fast in 5 minutes before writing this post. I'd love to see what happens with codeblocks code, if the same happens.

The codeblocks code on single threaded was a bit more optimized from VS2015 for this, made 950fps instead of 750. I am wondering how it performs with multithreading. Not bother to try now. That code would work on Linux, I think I read it's the MinGW on windows that doesn't support C++11 threads yet.

Anyway, I also took care of not using the same memory. I had precalcs for sines and colortable and made 8 copies of it for the 8 threads (although I don't get any more than 3x speed and that's the nature of the effect, too light and too fast, possibly ends on vram bandwidth, resolution is 1280*720*32bpp). I was almost going to try to see what happens if everything was looking at the same lookup tables. But this weird performance with VS puzzles me. Can't test anything. And anyway the code is a mess, I should scrap and design a way to pass jobs to a thread pool.

I am not sure I will be motivated to work more focus on some projects soon. I could equally well want to rest tomorrow and the day after. I'll see. At least I fiddled a bit with the thread code of yesterday. But I am scared of that code.

Also I spent time figuring out why the phone company can't come and install the phone/internet here. That's why I was a bit demotivated and then made a bath and played Doom and watched youtube.

p.s. Will I switch to some CPC or other work tomorrow? That needs change of focus, just take time finding the project, remembering the code, plan what to do next. Or maybe I should do what I feel like doing. Fiddling on this project is easier now, it's not even project, it's preparation of the framework for future demos/games.

p.p.s. I am going chaotic right now, no rigid plans, no focus on one thing. But maybe it's because I want to fill the time and write this post in a way that shows something is slowly moving. So maybe that's why I can't switch to more demanding stuff.

Sunday, 4 December 2016

Adventopolis #4 - Freaking threads

I need to write this, no matter what, and I hoped to finish some part before 11:00 but it's what happens when you get some nasty bugs and you want to just write hacky code just to test something and maybe write it better the next day. You think it's gonna end in 5 minutes and then you realize the last thing you wanted to try tonight doesn't fucking work and you are flipping tables.

Anyway, long story short, I tried std::threads on my PC framework and the idea is to test multithreading in some bitmap effects like the usual plasma. I have tried threads before by calculating something that takes like 10seconds and can fall to 5, 2.5 and so on. That worked like a charm. Now I am getting puzzled trying to create threads, split the image rendering in parts for each thread, then destroy them of course (task done). And I realize everything is going much slower and there are jumps. Wtf, using more threads makes things slower? Well yes, but there is a well known reason I didn't know..

Most of the tutorials on threads before was to calculate something that takes time. Create new threads, run some raytracing that might take 8 seconds, then destroy threads when you finish. But realtime effects have to refresh several times per second. It could be 60 times per second but if you are testing something for extreme performance, so if my plasma runs at 700fps and I am testing it if it can go more (don't know because of video ram bandwidth, but that's what I am curious for) then I init and destroy threads 700 times or more. And even if it seemed little, I realize this totally kills it and I get jumpy frames from 200 to 500.

And then it hit me. For things like that, I should create the threads in the start of my program, and let them continue running, having a boolean to wait for jobs, only when a part of the image rendering wants to run on a thread let it work with that, then when it finishes that part go back to waiting state. Don't destroy threads unless we exit that demopart or even the app. Maybe I could have for example four threads always on and waiting for works, till I give them some of my effects.

What I was thinking is something called thread pooling. Now I know the hard way. I have heard someone mentioning it and I thought ok that sounds good, I'll check it. Although I didn't know what that is. Now I thought it for myself and then by searching I found I was thinking of thread pooling.

So, because I at least wanted to see my effect running multithreaded correctly for a chance, I wanted to make a fast hack with some booleans. And I was getting into crashes. I knew for a thread pooling I have to sit back and think about how to implement it, but it was 10:30pm and I wanted to finish a fast test by 11:00pm. So, I was flipping tables, when my fast hacks where crashing. I thought I almost got it now but I stopped to write this post before midnight.

I guess I should scrap my code and think of thread pooling thoroughly. Tomorrow? I don't know. It's an interesting subject, however I am waiting for the day to switch to some other projects. This will take more time, I shouldn't rush it.

p.s. other than that, I spent most of my day playing Doom (classic) and then watching some 100% speed runs of Metal Slug series.

Saturday, 3 December 2016

Adventopolis #3 - NMS fail

Ok, I did actually work on the morning, just finishing some touches in yesterdays code, finalizing the simple tool that generates source files and testing by making few part sources and porting some effects. I was supposed to be doing the multithreading support but that's for tomorrow I guess.

I had to go to the city to relax and do some talk with the phone company (I am just in this city in UK that has the monopoly, three months and still no phone line and internet (though the 4G wifi box alternatives are much better than I thought but restricted in GBs if you want to do more)). Needless to say, not solved. Then I came back and don't remember what I did but at some point I decided to try NMS with the new Foundation update and learn how to create monstrocities for a base :)

Then I watched youtube. I need to watch some more and then sleep. I told ya, usually I work less during weekends :P

p.s. I also hope to switch to some other projects soon enough, although the PC framework miniproject is more motivating sometimes because I know what to do next and I can take it as slowly as I need.

p.p.s. Problem two. It's too late now to go out in the city to buy some Quinine. Damn!

Friday, 2 December 2016

Adventopolis #2 - Friday NMS

Strangely enough, sometimes I do more work during the week, coming back tired from work, than the weekend. There is this illusion that if I can produce stuff in 1-2 hours after work, imagine what I could do when I have two and a half days for free without the dread that the next morning I have to get up early.

But that's what gets me. I am more relaxed. I know that if I spend the whole night into something else, I can do things tomorrow where I will have 16 hours at my disposal. And then Sunday. And then Sunday comes and I feel that dread of another weekend ending and I don't want to spend my last hours before the work-week dreadfully pushing some code.

Thankfully it didn't happen today. Well, I am writing this and I don't want to procrastinate fully yet, and also I am working in easy straightforward parts of code where I know what to do next. But anyway, No Man's Sky has the Foundation update and I wanted to play it and thought to start playing but had to finish some code and now I am gonna start at midnight and not have much sleep for tomorrow. But I did more than I planned which is good.

In my base framework, I finished some of the automation code even yesterday. Yeah, annoying string manipulation (either on C or C++ I always found that part confusing) but now the automation works like a charm. It's a separate command line tool, I give it as argument the part name, for example "Plasma" and at various places in code there is the class PartPlasma, the enums PART_PLASMA, the code that inits Part *partPlasma = new PartPlasma(); and few more stuff. I have done it in a way with markers that works like a charm. Now all I need is run the command line tool with argument the part/effect name, it uses a partDummy.cpp/h template to replace, I copy the generate files partPlasma.cpp/h in my Demo folder, but also the Demo folder has Part.cpp/h with the Enums, so that also was coppied in Template folder and it's updated and I copy back, and then I add the two files in VS. Maybe I can automate some more but that's for now.

I also fixed a bit the input, I do have a logic now with JUST_PRESSED, PRESSED, JUST_RELEASED and RELEASED, four states. I try to integrate that with SDL Input. I think in SDL2 Input, SDL_KEYDOWN has a bit different logic than classic SDL (it's not a JUST_PRESSED but a fully PRESSED, but I need to check) which can lead one of my next tasks, to also make hook with SDL2 and see how things work different there.

There is more to do. One of my other plans is to add multithreading. The Corelib init will enable/disable multithreading, setting the number of cores, and I will have to think of a way each PartEffect will have a function which splits by cores.

Few more things and it could get more interesting. Maybe I'll leave this soon though, to go into other stuff. CPC? Or maybe some video things? Not sure..

Thursday, 1 December 2016

Adventopolis #1 - Little struggles begin

I am still sort of working on something, I am just trying to post something just before midnight so that it's not posted on the next day in the blog as time stamp. So, I guess at around eleven it will be a good time to start writing something everyday.

It's the first day but not as bad. I felt the little struggles, the little dread, but I was ok, didn't cared and had few straightforward plans that are easy to code. So after binge watching youtube I start coding an hour or two ago. Still on that framework to hook any software rendering lib, just reorganizing folders. Now I am just trying to do something (which I might do tomorrow of course :). The idea to automate some other things, for example every time I want to try another effect or part for a demo, I copy paste the init/run functions, rewrite the class or function name (PartRotozoomer instead of PartPlasma all over), the header guards, etc, so it's tedious when I want to instantly try something on new file with all the basic functions necessary.

So, my first idea was to make an abstract Part class with virtual functions that have to be implemented, so when I make another class PartPlasma inheriting Part, I will be obliged to make an init and a run function, I will have few basic member variables (screen mode and ticks timer, although those are provided from main script when calling run for the part). Now, I don't want to type these, I want to do Add->Class with Base=Part in VS or Codeblocks and preparing everything directly. It doesn't fully work. It doesn't add the pure virtual functions ready. VS puts #pragma once also, Codeblocks does it with guards, and there are few member variables I have to add myself.

I might make a small tool to assist me, with a skeleton of the Part[Effect] class. And then go replace [Effect] to whatever. I might just do that tomorrow.

I don't know if I will continue with this project later on these 3 weeks. I might switch to CPC or something else. I also dream this framework for games, making generic well thought modules for sprite rendering, menu system (for options, etc), input manager where I won't write e.g. SDLK_SPACE but I will have some generic defines like KEY_SPACE and the person who hooks a library would somehow provide his own defines or mapping from SDLK_X to KEY_X. And for gaming purposes you could do KEY_JUMP, KEY_SHOOT assigned to those,.. I don't know, I don't know, I have to think how to do it. I want this time to design it better in every aspect. I dream of making a simple 2d game example and then porting it easily from PC to GCW Zero, GP2X, even DOS.

But I don't know how much I will work with this now. Maybe just finish this Part source/header creation tool, easy. And write one/two more hooks to test how easy it is, one for SDL2 and see how this works with SDL1 or 2 on GCW0 for example (everything should be similar, but maybe the button mappings to keyboard mappings, will see. Maybe separate hooks called SDL_GCW0 and SDL_GP2X, etc should be made, maybe not). Then, I don't have straight plans, some parts need more thinking and I want to work on something more straight forward.

Coded at nine or ten in the night, usually at that time after procrastinating I don't want to. I am like NOPE. When you start with binge watching youtube (do I do anything else these days? Oh wait,. NMS foundation update, shii...) and the time has passed and you feel the dread of not having worked and afraid to work, it's more easy to say fuck it I am doing it tomorrow. But because it's the first entries here and I have to work on even something I did. And it was few straightforward code changes anyway.

Tomorrow is Friday. I will have more time but will I work more?

Wednesday, 30 November 2016

Adventopolis #0 - Tales of Procrastination

This is a little procrastiproject, where I make something like an advent calendar but not exactly. Simply, every day I will be forced to make an entry here and write something about the projects that I am currently working and how bad it went. It can be humorous or lazy or whatever happens or serious attempt to get back on track (I have not worked much on code since the last update).

It's an ongoing process trying to fight the procrastination even though I believe it's a natural condition. The unnatural will be to work on vanity creative projects in the evening after work, tired and not motivated enough, not having the reason to do so rather than just relax for the night. Yet again, I realize again that there are some small and larger things I want to do, new frontiers in coding, older and newer ideas never resolved, sitting there and begging me, what could be done, what are the possibilities. When you have the skills but your are not conscientious.

So, just a test, what if I first posted every day till 22th of December (I will be on holidays later on), would that force me to work a little bit more so that every day will not be "I binge watched or done nothing" in excess? Most probably not. When you try to push it, it come back badly. It feels even more dreadful. But just a test..

..or maybe I just want to write something, to feel fulfilled even if I didn't worked on my projects.

So what's going on today? I binged badly on youtube and specifically Dark5. Maybe I'll spend 15 minutes on reviewing some code.

What do I want to work on? I stopped working on the CPC wolfenstein for a long yet I'll plan to come back at some point. As a change, I was working on a new framework for testing effects and doing software rendering stuff, but mostly it's the same boilerplate SDL code but in a way where one can hook his own class with equivalent for other libs, TinyPTC, DirectX or whatever. I just wanted to design something new in a way that the core for a lot of things, from screen buffer to input, is abstract, not having any dependencies upon libraries, but having hooks for someone wanting to connect specifically a lib to it. It's a small thing I want to grow, I am just overthinking it right now, reviewing code I wrote hastely few days ago to see if it's how I like it. I was between the "write some code fast without overthinking it to motivate yourself" to "maybe spend more time to carefully design this and don't bother if you don't finish it soon" (which I will do today, review what I wrote with more pace and make some notes of what I want to change, what I like and whatnot).

But I may change from that soon. I want to work on some parts on the CPC Wolfenstein (since this is already rolling and it's more motivating to add stuff). And then few more stuff I want to at least start with before the end of the year. One is Sam Coupe. I wished to have release something by this year, so maybe I'll roll a 256b-512b intro with some code I have, no big demo yet. Then there was for more than a year my big dream to start something on youtube. One of the ideas were videos explaining demoscene or retro stuff in some detail with good visual animations and not superficially like some gaming channels that I see try to explain graphics. And specialized subjects you don't see, like some crazy trick on CPC or insane optimization ideas used in the demoscene. Another thing I would dream was some videos more on the gaming side, but discussing for example non-linearity in oldschool FPS or other similar subjects in good depth. I am thinking of videos aiding with visual animations, in the way I am understanding algorithms as a visual mathematician.

I might start giving it a try with some code or video production and voicing with some of these (and maybe I am thinking to try something with the oldschool FPS map, trying to compile Zdoom code so that I code it to aid me in a specific visualization on the map, outputting frames and maybe then connecting them in a video). So, maybe I will make my first attempts on this during this advent calendar. But no complete video will be produced, just a test of how this could work.

But my youtube ideas is something that needs tremendous amount of focus and I realized that by the way my current habits are on procrastination (which is not with the negative aspect of it, but the realism that it's quite normal to come back from work and not want to work furiously on these, but only dream of the posibilities if it was possible for me to be a cold robot) there is no way such big project as that to ever take form, even started. Code of small stuff or even slightly bigger is different because you can code a small fraction and keep it in storage for a year, but youtube needs frequently updates (and I plan if I ever start to be less than a video per month but good quality and researched).

So, I'll try to make a small Sam Coupe release at some point, work even 5% of my youtube ideas (start preparing the tools, test the way of production and voicing, make a 10 second snipset and see how it looks and sounds), work some of the days on the CPC Wolfenstein (I have lists of things to do next, so it's easier to not get stuck on thinking what to do and act fast) and maybe review my agnostic software render framework and see if I will work with that too. Also, in two weekends is a new Ludum Dare and I might think of taking or no taking part for the full three days, just to flex my motivational muscles.

You will know how it goes and what moves or not, worst case scenario I procrastinate to even update this advent thing, I sense it's so bad that it feels not worth to continue. Or at least I can finish every day till before my holidays and it reads back like a big joke of procrastination tales.

Tuesday, 1 November 2016

Progress Report (CPC Wolfenstein RPG: raycast errors and naive zoom)

I haven't gotten to write my articles on the mapping and raycasting techniques yet, these need more motivation or time (and I rather spare it for coding the engine) but I decided to give from time to time some progress report on whatever I am working (this might even include other things I am working, irrelevant with CPC or the engine) from time to time, even to motivate me to work on things else I have nothing to say. I am experimenting with various things about motivation and what kills it (or why what you need is full determination, not motivational tricks) something I want to talk in my other blog maybe.

But anyway, I am still happy with the little improvements I do day by day even after my daily work where it's hard to want to spend your time on such project instead of being lazy (with youtube or look Brutal Doom 64 is out, my god it's amazing fun!). I now have some determination to finish this project by the next year, which means fixing all I want to fix and all basic tech for this engine (fix all the raycasting bugs, improve colors/fading, have zooming sprite algorithm with items position projected and clipped ready, make some structs and editor for basic game objects) which I hope it will be this year or early next year and then go on for a game. No fucking around with fiddling and showcasing a tech demo for years anymore, plan for working on a game after finishing the important parts of the tech. I don't promise anything but I just say I am now determined to plan properly and work on this whole thing as a game and not just an engine so that I can release something next year and move on with other great things.

In the screen below, you can see the little branch I did (the SDL simulation of the raycaster engine) so that I can investigate those ugly bugs, usually when a ray passes through the corners of a block (I almost know why this happens, I just need to find a good way to fix it). In the left side there is the accurate raycaster (the one that doesn't run on CPC else it would be much slower) where you can see 2 rays passing through the blocks instead of stopping before. It's always on the corners. On the right side is the optimization idea where I send rays say every 8 steps and if it still hits a similar block I interpolate in between, so that can cut the rays cast by 2,3,4 or almost 8x. The wrong single rays makes it interpolate all over behind the blocks it should stop. It creates weird diagonal popping walls sometimes. I get these mistakes only at specific position and angle of the player.

And here is an ugly picture of the zooming sprite in action. It's in front of the walls and behind the weapons layer. The sprite is some random pixels, I can do better than this when I port the data of a bat sprite I have from sigh. Or finish that mini editor I want to do for drawing sprites/walls/weapons and map, and automatically export C or asm data lists. The routine is now pure bruteforce C. It is optimized to avoid divisions and do it all in 16bit fixed point, but of course it can be much faster when I rewrite it in assembly. I start with a 16*16 sprite (I think my enemies and objects will have sprites of widths or heights of 4/8/16/24/32 or others in between. This is ok since the byte size of the play screen is 64*64) and zoom from far to 4x. At 3x-4x the speed drops dramatically. I calculate 4 VBLs lost. Sprites usually won't zoom fully to screen in the game, enemies will keep a distance and objects will be smaller. Yet, I am already planning an assembly code for this, something I might explain when I finish it and could be 3x or more times faster.

Other than that, the weeks that past, I was fiddling with random code for non-projects. In one instance I was testing various code on my DOS machine. One day I even tried to go from CGA to SuperVGA. I never coded on CGA so I just tried to see how it works, it's quite easy. But I haven't found how to change palette or try something like 160*100 mode. Then as I was reading an article, I noticed it would be easy and compatible to try Svga 8bit resolutions, from 640*400 to 1280*1024. It's the same resolutions the demo Countdown from Realtech were offering. Vesa 1.2, no need to load Univbe or something I guess (not sure if it would load in some old Svga card though). I just tested my Pentium 3 @600mhz monster with a run of the mill plasma. 640*400 did 200fps, 1280*1024 did 35fps iirc.

Then I was binge watching the new Black Mirror series and playing No Man's Sky from time to time. Also watching some of the C64 X demo entries and still I haven't found the time to play the CPC games from the new retro gamedev compo (but I played a bit of Imperial Mahjong and Pinball Dreams).

At some time in the past I also hoped to try some SNES code, I prepared my assembler and compiled the first example, but that is on hold now since ages. And contributing some effects for a friend's DOS demo, a bit on hold too. What I plan to do soon is focus exclusively on the Wolfenstein engine and use my new Trello account to plan/motivate finishing some stuff here and there. When things clear up, it would be more motivating to start working on the main game. Maybe I'll make the proper write ups for the tech at some point, if not at least some progress report.

Tuesday, 18 October 2016

My CPC Wolfenstein engine (map editing tool)

It's time to continue by revealing the little map editing tool I started creating, just for the purpose of testing textures and designing the first map. Of course it's a crude tool I made just for the occasion, I once made to give to the artist so that he can try a texture loaded as a PNG (designed with CPC palette in mind), size 32*32 or less. It was never planned to be the level editor then, just a testing tool, but it can be expanded in the future in a way so that I can add monsters/items near blocks and additional metadata per block for scripting events.

Right now, you can draw/erase with left/right button on the down left side on the map, while seeing the blocks appearing in realtime on the upper window where you move with arrows (it's a simulation of what you expect to see and play on the real CPC, but on an SDL window in Windows). On the down right side there is the texture, the mouse scroll wheel will go through four textures atm. These are stored in a folder named texture1/2/3/4.PNG. It's just not complete atm, no menu to edit the mirroring of the door (which is hard coded for one of the textures), but there is also a rule. If you upload a texture that is something like 16*16, it will tile normally over 32*32. If you upload something bigger, it will just use the upper left 32*32 block of the graphics. Also,. there is a simple search through colors for palettes closest to the CPC palette. If your PNG uses colors very similar to the CPC palette, it will use those. But throw an arbitrary texture inside the folder (like some 32*32 Minecraft textures I tried) and it will automatically try to do it's best to match CPC colors, although usually it will look like crap.

Btw,. in the screenshot you see the unused two frame bat enemy sprite plastered on the wall. I might try to use this one (but maybe with dark blue instead of black) for my sprite enemies. Some other good news is that I am finally investigating some code for zooming sprites so that we can finally have some meaningful items/enemies in the game (a lot of work has to be done for that, not just zooming sprites, but clipping and calculation of position and zoom factor based on the camera visibility). I was trying some bruteforce slow C code and while you will get 2-3fps when sprite is filling fullscreen (something that will not happen with most sprites, I had to zoom by 8 to get this) this is very slow C code and I am already thinking of a nifty assembly solution, with very small unroll codes, that by calculating cycles doesn't eat more than 1VBL for 3-4 partially zoomed entities. And usually there will be less on screen and smaller items that I will not allow very close zoom in an RPG style game (you will be blocked by such so you won't get too near). And I am already thinking of transparent texture walls (like iron bars and doors) in a way that they can be drawn correctly with sprites and rest of the walls. I have some good ways to solve these problems, I just need to finish coding them first and test.

There are more stuff I want to do writeups for:

  • Texture repeat/packing/column offset engine and the cool things you can do with that.
  • Raycasting math, optimizations and interpolation tricks.
  • Wall rendering unroll codes explained.
  • My ideas for zooming sprite and transparent walls.
The thing is, most of these stuff need more intricate shapes to be prepared and careful write up. So, I am not sure when the next one will be (but I want to cover some of these bigger cool stuff). Meanwhile I might write smaller stuff or little news of progress. And even if I don't for few weeks, this means I might have focused more time on working on the engine rather than writing about it. So, don't expect anything, maybe it will take one or two weeks for the next update. But things are going good and I am motivating myself and planning things ahead.

Thursday, 6 October 2016

My CPC wolfenstein engine (history and progress)

I look back in my old emails and backup folders and repos, one of my biggest projects, beyond regular demos, to build a 3d maze wolfenstein engine for CPC. I was aware it's possible since coders in C64 and Spectrum have done this before and it doesn't involve anything other than fast software rendering and hard math (and a lot of sweat and tears).

Till this day I don't think it's complete, it's far ahead from the goal of perfect optimizing, part of it is still in C instead of assembly and there are few left muls and divs here and there to avoid. Meanwhile new ideas of cool things to do with this engine are coming through, only thing needed is the grand motivation to focus and work on it and hopefully a game.

Yesterday I released the first official playable preview of the engine, in four (six) flavours, you can find a download link here. You will need of course a real CPC or the Winape32 emulator and there are all the versions inside to try (64k, 128k, wolf/rpg, gx4000 cart).

So, some series of blogposts could be a good opportunity to remember the past and write my thoughts about the future, possibly motivating me to experiment more, improve things and occasionally post some progress here in the future.

  • 15th December 2010
    • It seems from my backup files, during that day I started working on some new projects and it's not just the first iteration of the wolfenstein engine (which was just the fast wall rendering algorithm without the raycasting yet) but also an unfinished 3d engine project (just rotating and projecting few 3d dots and later on rendering as points or lines). Fun fact, these were started in the old PhrozenC compiler (much much slower and more bulky in code size than the great SDCC I am currently using).
  • 29th December 2010
    • I release the first youtube preview of the engine. This is running at 25fps but that's because the math (distance of columns from camera) are precalculated data in memory for few frames. It's really the raycasting that it's costly and that's the only video where the engine looks pretty smooth but it's just wall rendering and zero math calculations. It looks nice as a teaser but the reality is a lie.
  • 10th January 2011
    • port to SDCC
  • 23th February 2011
    • First backup called Wolfenstration, so this could mean the start of my demo Wolfenstrad using the engine (Wolfenstration was ment too big for the logo designed by Voxfreax, so my brother much later said "Hey, why don't you just call it Wolfenstrad?")
  • 5th April 2011
    • Just as a parallel history (of the 3d engine I was designing for the purpose of doing flat 3d polygons, still pending) that's the day I started trying to write a triangle/polygon rasterizer. It's really a n-gon rasterizer, more suitable for flat color polygons (gouraud or texture won't interpolate evenly for each scanline unless you go triangles) of any number of edges. Used in 2d on my part in 30 years megademo. Still need to work in a future project to finally produce juicy flat and even gouraud cubes (my dream!).
  • 27th October 2011
    • It seems that during this day I started working on the RPG version of the engine, just moving one block per time and 90 degree rotations. The engine was much much slower and buggy even for that then (less than 5fps and would reset to AMSDOS at certain angles).
  • 18th March 2012
    • Wolfenstrad is released at Forever 2012 party. Finally a good use of the engine in a demo. There are many funny and interesting things about this. The real engine is still not playable (very very slow and crashing). In most of the scenes you are in a center rotating around but not moving. It's using a clever precalculating for this where 360 degrees of rays are calculating the distances before each part and you just scroll through these (but they have to be projected or fishbowl corrected to not look static). The walk through part is just precalced distance data I managed to fit. You can still realtime rotate through these scenes, so an adventure game where you fade in/out in new rooms and observe but not move would still be possible with this version. Interesting are also the effects on wall, most of them are pretty fast, based on column offset mapping tricks, an element of the engine which will be really really useful even on the game I prepare, both for fast special effects where you just change offsets of column lookup instead of changing the textures. Also suitable for fitting more textures ready for display in the limited memory and a special way to express them, so that you can have a pure wall and then a wall with a torch and then a wall with a lock without storing three times the texture. I really want to explain this feature in a future blogpost and what you can do with it, it's pretty cool!
  • 23th October 2015
    • Some weeks before this date there was a CPC gamedev competition and I thought I could maybe take part or just boost my motivation to work on this engine. I never finished the game I was planning (which I concluded it will be the rpg version now, it's an easier mode to avoid some tech problems in this engine and more interesting as a game than a pure FPS). But this compo forced me to relocate memory pages so that I have a port of the engine running on 64k CPCs. I even made a GX4000 cart version and released the first playable preview on youtube. That was the time that I used some optimization techniques to make this from unplayable to playable and fixed the problems creating crashes and some of the visual bugs but not all.
  • 9th October 2016
    • The decision was taken to upload the first playable preview so that CPCists can finally feel how the engine plays, walk near the walls (find the ugly glitches :), discover that the dream can be real (and there are still a lot to optimize and fix, this could be more smooth and nice). Such a preview was actually already shown privately at Reset demoparty although not the new RPG versions with knife weapon and ugly fading walls (the last experiments before I abandoned the project again). This is a decision I am fine with and it might release me a bit from the feeling of having worked with this sporadically for five -six years now and not having people see it in the real CPCs with their eyes. Meanwhile while doing so, looking the code again, trying to recompile, I started being inspired, thinking of some ways to fix some more bugs, how to experiment easily and fix the fade colors, try some new rendering stuff and gameplay elements I haven't thought before. I hope I will truly be motivated to work frequently with it (I have made a Trello account to organized plans and ideas for this and other projects to keep the ball rolling now) and post some blogpost or screenshot here and there.

So, truly a lot of things have happened in my life, mostly getting my master's degree, finding a new job and relocating to UK. The first version and demo was coded in Greece while I was unemployed and now remembered after I settled down here in UK. It's a long time, nice to remember how long it takes (although I wasn't working every day regularly on this, there were long pauses and comebacks).

Wednesday, 20 April 2016

On Doom and linearity again

I really like this iconic image all around the internet, manipulated in various forms, making a point that modern gaming sucks, wondering what happened to the genre, lamenting the old times. Guess what, we have all been lied! The original author of this image wasn't intending to represent that idea with this image, he thinks it's misleading to use it all over the internet to argue how games suck these days. Link to the talk where it first appeared. He is actually a person who used to make Doom maps in some of the best megawad collaborations ( Requiem or Memento Mori 2 ) and is working as a level designer in major titles ( Dead Space 2 and others). Here is another talk with an interesting analysis on what Doom does well. It's just funny that a person who used to make Doom maps and likes some elements in Doom, popularized this picture, wanted to say something entirely different than what is spread out there (maybe the fact that his design in Dead Space 2 while linear, is still fun to play). That's just to inform you on something we didn't know about the origin and the meaning of this picture. Although I am still firm on my opinion that I want games more like the map on the left and less on the right.

I have some more thought about it. I am binge-playing Doom WADs these days (using the Brutal Doom MOD, shame on me) waiting for the release of Doom 4 (or simply Doom, I hate when they do this with titles of famous franchises,. like it's the Definite Doom) which I am sure it will disappoint me (I'd rather see new franchises that try something different, the Overwatch and Battleborn games seem interesting, even though I've never played something like this before (inspired by TF2 which I also never played)).

Anyway,. during plays I keep wondering what elements of level design from different mappers I like or dislike. (Right now I am playing the Community Chest series in succession, each mapper has a different idea on linearity, secrets, difficulty, monster and item placing, architecture, texture usage, open spaces, etc so it's interesting to observe which maps I enjoyed most and why). Some of the good elements of Doom concerning monsters/gameplay were already discussed in Mattias Worch second talk (I really like that idea that resonates to me and people who have been played Doom for years so that brain cells are dedicated to specific audio/visual cues and reactions when you open the next door and observe a specific monster configuration and reach instantly, taking decision on which monster to kill first or if you should retreat behind a column while strafe shooting). But what I am curious about is those elements of how the map is designed and I want something more than the linear exaggeration in that mock up image. Because one element that I loved in original Doom was exploration. That one is missing from most games, no matter how violent or frantic action they have. The new Doom or the mock ups of old retro FPS might have crazy violence, frantic action, non regen health, no weapon reloads (those are easy choices) but not even a single one goes for the more interesting oldschool FPS levels.

But I noticed something while playing a specific set of maps (they weren't on CC, not very known, I don't even remember it's a recent download and one episode even used Doom Alpha textures!). The guy had made a totally extremely non-linear set of maps that would make you being lost for half an hour. A very frequent theme would be rooms would be seen from windows through windows through windows, kinda like John Romero's E1M7 but way more confusing and exaggerated. This also made it so hard to reach to the next keycard door while looking at the map, because a window sector will still look like a passage. It was a fun set of maps because they where huge levels filled with shotgun guys and other small monsters, perfect for sniping through windows, but then you had this flaw where it confuses the player to death, even experienced players.

And then it hit me! You can't say that Doom is the epitome of non-linearity. Some of the original levels can be quite linear if you think about it and people will disagree with what that means. While you have rooms connected to other rooms, even entire sections just for additional exploration or finding health/ammo, in many levels the main path from start to end would technically look like the fps map design image in the right. Maybe with some hoops and loops sometimes. Or backtracking. Think about, most levels are small sections of donut shaped rooms, side corridors, but a colored key door. You have to find the key to progress. You can't necessary do A without B. Can't finish the level without getting the red, then blue and finally yellow keycard (unless you do some crazy speedruning feets or happen to make the Archvile open the door for you :P).

I also noticed that some of the levels I loved playing in CC series had the specific characteristics (not always all). Big spaces and outside areas so that you can move freely and observe nice architectures and pinpoint kill enemies from afar. Some very good realistic buildings and places, so that the level is atmospheric and interesting, kinda like telling a story about the place but without cutscenes or dialogues. And third and most important, the level progression was so fluid and without much interruptions, so in a sense it was more linear going from A to B but masked in such a way that there is still the feeling that you are exploring and not pushed through a direction. Meanwhile there were side rooms and secrets, you could backtrack if you wanted, some rooms were still connected so that there are different passage ways, but somehow the progression was planned such a way that if there is a red door on A and you need to go to B, then after getting the red key another passage might open that leads you back to A from a new path where you can directly use the red key to go to C.

I know, it's a strategy I have seen some modern games use frequently that it becomes predictable (the inside levels of Borderlands among others, maybe Half Life 2 popularized these game design techniques I have to check this). But the difference is that new games do this in a way that this is just your path and there are no side rooms and feeling of something different to be discovered, while the good Doom levels are a mix between linear paths and non linear side rooms and connecting passages. Maybe player psychology is taken in account, because if I get the red key and maybe not notice that a new passage has opened, I will do tedious backtracking from the old path, or maybe the old path has closed now so I really have to observe the new alternative path (but that would seem more linear, less choices, more forcing you only through one path). Sometimes because of player psychology I happen to get stuck at a point because a side wall opened with a button that opens the path and wandering around the wrong places for 10 minutes (and sometimes, the splatters of Brutal Doom will make a switch so red that you can't see the button, yes this happened a lot leading in confusion :).

So, there is a balance between linearity and multiple paths, specific look in the psychology of where the player could go next or if they will notice that something has opened (in a recent let's play with John Romero, he describes how in E1M2 he let people playtest his map and most preferred one of the two side doors that go to the red key and how you can never be sure why this would happen and can't predict it will happen with all players) so that the experience is streamlined in a way that doesn't feel as restricted. And of course there are different opinions on this. Some levels that I would consider non-linear, some players could think it's linear as hell. I remember one of my maps, where I wanted to make it feel like an explosion sounds (hidden crushers smashing barrels) and the door behind closes, later to find a smashed wall, and in progression paths where closed and then opened, leading indeed into a very linear directed gameplay but that's just for the 20% of the game, much later it opens and you can visit everything. I got some reviews calling it too linear. I didn't thought it was or maybe people quit on the beginning. I just wanted to tell a story with the level events at that point. At least it was mostly non-linear when a trigger later opened all the restricted doors, the difference with many todays games is that a door always closes behind, being like 90%-100% linear.

Sometimes level designers get very enthusiastic with a specific element, my thing is doing crazy stuff that seem clever or impossible with the engine. I adored the levels that either have a very life like architecture or funny crude stuff done with sectors (like making acid spills, broken pipes, real life objects, designs telling a story that this was a real place not an abstract bunch of lines) or did tricks like bridge above bridge. In the passion to create such things we forget other aspects. Sometimes we designed very cramped small passageways (while I realized, the levels with more relaxed open spaces and outside areas became my most favorites) just because it fits a narration of the hero crawling through scary passageways, with specific functions. I remember such levels, and while they have very realistic designs with sectors resembling real life breakage and machinery and such, it's obvious the author obsessed over detail and forgot gameplay. There was a level in CC3 which had such kind of design, some passageways where you have to find switches to raise the level of water, sectors where representing turbines, etc. I fuckin spent like 20 minutes trying to progress, just wondering, sticking in walls, going around, not shooting anything. And I did kinda liked this level for these life-like design ideas, but imagine someone who doesn't care about architecture and tricks, rather than pure shooting. It wouldn't appeal to anyone even if as a designer I kinda like it. Sometimes I have some hard times in specific levels and I am experienced with Doom and finding my way out, and then I am wondering if I struggled for 5-10 minutes, then how about a newbie who hasn't played Doom before?

Then come to think, maybe some non-linear designs is of your preference, but would they work for the majority of modern gamers? You would beg game designers to map levels more like Doom (at least they can mix the linearity) but maybe there is a director in a big AAA game company that says to the team "No! Remove that corridor, it would be too confusing to inexperienced players". And maybe as a director he is right, because that would not drive away the less hardcore players. Maybe few game fans will be disappointed but the game will sell in the majority and so the director has done his job well. You'd have to base upon the few game companies that have passionate game designers who want to make the game they want to make or play, not what appeals in the majority.

But yeah, that's the issue. I think we obsessed a lot with linearity vs non-linearity, always targeting for the far end. Linearity or non-linearity are not inherently evil. I've seen how a very non-linear Doom map confused the hell out of me even if I found it interesting as a level design, while some less linear but mixed levels with some great atmospheric environments but a hidden linear path that tells a story were my most enjoyable levels. While most AAA games do 90-100% linear designs where they even close the path back or have invisible walls as to play it safe and not confuse the players. In my view I see most modern games like this. Others might have a different view. I am not saying that the solution lies in the middle, because of tastes. What do you like? What maps did you enjoy the most? Would the majority like them? Do you want to keep your job? Do you want to make the games that you would love to design or play yourself? Would you rather fixate on a very linear path just to tell a story?

So, in the game community we have the tendency to say "Modern FPS suck, I want to be lost in the most complex Doom labyrinths". Or "Doom labyrinths are horrible game design, show me the way point and close all alternative paths so that I don't have to search".

p.s. Now I have to find the maps I really loved, keep some notes, and design some new Doom maps myself (so long since I last did this). It seems to me that what makes Doom great or what makes some levels better is something not so well defined and might be different from person to person. But it's good to observe more closely and take some notes and find interesting patterns.

Saturday, 12 March 2016

So, there it is!

One more final merge. There is nothing more to merge. I couldn't keep with some of my blogs. Well, I don't have the motivation or time to write frequently in most of them anymore anyway. But at the end, it makes sense to connect Plasma Fun with Computer Hermit. They both talk about computers, one is more on the light side reviewing games and demos and just having nice screenshot of stuff, the other started as a serious ranting about things computer related. I think that's for the best. And then there is no way I would merge anything any more, Optimus Monologue is totally different than this one, it's two sides of my life, one thinking too much about life and ideas, the other about computers. Unless I decide to create yet another new blog, this will never happen again.

I might only move some of the blog links I still care about here and delete Plasma Fun once and for all. I am not sure if I will review games soon or just rant about game design or computers or maybe even talk about programming. But now everything will be together, instead of two separate blogs with minimal visits, one more abandoned than the other.

Maybe a new post - games I would have written about

This is a quite abandoned blog. Well, I have three of them, and sometimes wondering whether I should connect them all at once. But how many times have I done this thing? Deleting blogs, merging blogs, then deciding to separate them again then merge again? I have to decide. Certainly I decided to never make a new blog anymore, unless there is a special reason. And what should be merged? I would like to kill some of my blogs. Or they don't match together. (But I think I might do one last merge and keep it. This blog is more close to Computer Hermit and also less updated).

I would like to write about some games like in the past. I stopped at the first Borderlands and Test Drive Unlimited. I could have reviewed what I like and dislike about the sequels of these games which I played to death. Or there are few special titles that I would definitely like to mention. Special types beyond your typical AAA game. Indies or almost AAAs that I specially adore and are my favorite games of the year. But maybe I'll make a list for now:

  • Legend of Grimrock 1/2
  • Life is Strange
  • The Talos Principle
  • The Witness
  • Spelunky
  • To the Moon
Those are. Those are some of the recent games that I am really glad they are out there in the game industry, making things better than playing another AAA title with boring cinematics and QTEs. And maybe I forget few more.

Also, I'd like to mention some recent oldies I replayed and appreciate (some of them remastered).

  • Deus Ex: GOTY
  • Strife: Veteran edition

And of course:
Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale Undertale 

Hehe, the Undertale madness is insane. And I quite liked it, even though I have more love for some of the other games in the list. But anyway, Undertale deserves this too for doing something different and surprising with the retro rpg genre.

And there are quite more games I would like to talk about, also Brutal Doom and it's impact, why the community is divided. Also sometimes I play regular Doom or Brutal Doom and wonder what is the thing that makes it so unique compared to modern FPS. Or discuss what are the good elements from Serious Sam or how many new things had Duke Nukem 3D made and how back FPS are (or they followed a different route of cliche cinematics and linear storytelling with boring action). I could make a lot of analysis on some game design subjects I come back a lot of the times and wonder about.

Or maybe talk about demos and other stuff that I wanted to cover in this channel too. Maybe..

p.s. Or maybe do the merge. That will be a final. One is my thinking about life and ideas blog, Optimus Monologue. The other should be Computer Hermit (and I get rid of Plasma Fun title which is weird, didn't gave it much thought then). I know,. I would be killing some links to this blog, maybe the replies to the messages are copies and maybe I have to move some of the good links before deleting it. I think I'll make the move..

Thursday, 21 January 2016


Sometimes how specific terminology has come to stay make me furious. It shouldn't matter since it doesn't affect my life. But strolling through gaming or tech forums, I might end ranting to the air, search for other people hating the same terms, rejoicing in the thought that I am not alone.

Today it was 2.5D. I don't know how I have come here, maybe from articles defining raycasting, raytracing, raymarching, sphere tracing, remembering all those terms that are so intermixed with each other, sometimes even in graphics articles or papers. Later, on wikipedia talks about raycasting, people mistakenly calling Doom or Duke 3D raycaster based, also named it 2.5D. Although does it matter? What if we use the terms but then if misunderstood, describe in more words what we exactly mean?

2.5D. That's the problem with this term even between those who use it, which is used to describe various different cases of rendering and gameplay. They might be meaning 2d gameplay in a 3d environement (Trine series), 3d gameplay in 2d rendering (oldschool isometric games where you could still climb over objects and above enemies, e.g. Knight Lore), or games with 2D maps but 3d gameplay like Doom (about which, there are many misconceptions I'd like to discuss another day). And there is even misunderstanding of what they mean, for example some consider the new Mario World 3D on the Wii U to be 2.5D because sometimes the level design forces you to move through one axis. What they want to define is so diverse, that it's better to describe both it's gameplay and rendering in more detail than shoehorning it into one category.

I personally hate the term at all. It's meaningless. I read it was used as a derogatory term to differentiate classic first person shooters from later 3d polygon games. And sometimes I like to joke about it, talking about fractal dimensions and especially 3d quadratic koch surfaces (exactly 2.5D by Hausdorff dimension :).

It's isometric, so it must be 2.5D, right? :)

In fact, come to think, even the most modern 3D polygon games, what they really are, is projections onto the 2D screen. That's another way I like to mock this term. Your nextgen 3D games are 2D. Not even a half more :P

p.s. I read so much misconceptions about Doom that I will briefly mention. First, it's not a raycaster, no rays are cast to determine the wall rendering, not everywhere in the code. But the walls are still rendered with stretched column rendering just like wolfenstein. Then, people said you don't have control on the vertical axis. That's not true. While the maps have sections called sector made only by 2d vertices and having information for floor/ceiling height, all the things (player, enemies, items) have three dimensions. You can walk from a ledge and fall or climb stairs. They could easilly have added jump function in the game. Someone said there is autoaim when you shoot, which shows the limitations of the engine. It's not because of limitation. They could have done it. They just didn't have look up or down to aim the crosshair in one axis at the time because it would be harder for the gameplay. Also, there is an effect where you shoot a bazooka that hits a wall below a monster on a ledge but the explosion radius damages it. Just lazy coding. Monster has x,y,z. Your projectile too. Could do 3d distance or 2d distance like it does and another 1D distance check between heights of projectile and enemy. When imps throw fireballs at you from higher ground, the fireballs really move on a 3d linear path. Cacodemons fly above and below. If you shoot a bazooka on a higher place and later another monster crosses the trajectory below, it's not hitting it because it's above. At least, there is true 3d gameplay, things move in three axes and the 3rd axis matters.

p.p.s. Come to think, that's the best thing 3d graphics technology (no matter if real polygons or projections of 2d walls) has given us. Not more brilliant visuals, but an expansion of the gameplay space. Suddenly you don't scroll in front of a background, but you can discover things behind it, find hidden rooms from the other side, hide above or below, reach and attack from other paths, new views of the same data. Think Deus Ex. So many unique paths to infiltrate the same place. One could argue that you could have some of these things in 2d games but this has expanded a lot in the 3d space. That's another reason why it makes me mad to see another linear on-rails FPS with "brilliant" graphics but very restrictive paths. I could joke another time and mock modern FPS games by saying they take the 3D and restrict it in 2.5D. If we wanna play like this, Doom, naively called 2.5D, has more exploration and expansion of your 3D senses in terms of gameplay than your average modern FPS.

p.p.p.s. Yeah, I am ranting. I could be writing more if I didn't stop now..