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?