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?