Showing posts with label OpenGL. Show all posts
Showing posts with label OpenGL. Show all posts

Wednesday, 2 December 2015

SDL - Bug or Problem with SDL_RenderFillRect

Got one of those annoying debugging problems going on, I'm not sure whether the problem is with the presentation buffer, or the data I'm drawing.


This code, draws a cross within a rectangle I've defined, and then it draws a hollow rectangle around them... Annoyingly, the calculation I've used for adding the width & height to the location makes sense, but it appears the rectangle is one pixel less in width... So the SDL call calculates or 
uses the rectangle to draw.


But, that's not the problem, below the code drawing this, I've asked it to actually fill in the whole rectangle...


However, the result does not fill in the rectangle...


I've tried this in both Visual Studio and Code::Blocks, neither seem to want to fill in.  I'm using the same colour, blend and settings, as you can see in the final code listing, just the call to the render fill rect function does not render a filled in rectangle.

Any ideas?

Monday, 28 July 2014

Imperial Conquest - Atari ST - My Version Pt 1

Some of you out there will know of my background as a war-gamer, yes I started out playing online games - and games with other people - as grand table top strategy games...

I've played many, from way back on the Atari ST with my favourite, and first, strategy games (like Carrier Command and then Imperial Conquest).

I particularly likes Imperial Conquest, it was written in STOS (a dialect of basic) and featured on the cover disk of STFormat.  And I wrote off with £5 of my pocket money to buy a real copy - which came back as a diskette - no box, it was a proper indy game!

The idea of Imperial Conquest was you had a world view, well a Europe high view, which showed the cities and armies and fleets as just dots... You could then click and see a smaller snap shot of the land... If you got it clicked on the wrong spot, you just had to go back up a level and go back down; there was no scrolling...

You held cities, and from them each turn you got income, a turn being a month, and then you paid from your income for armies/units you controlled, and you moved these army counters around to take other cities.

Very basic, but very addictive...

So, my next personal project is going to be an Imperial Conquest clone, this is to a) get me back into coding and playing war games, and b) to teach me some more platform portable 2D OpenGl Code.


 The first thing I did was trace an outline of Europe, using Red for Land, Blue for sea and orange for rivers.  These will be my terrain types for now... And I wrote a C# program to parse this image into a raw map, the map can be any size, I've tried everything from 640x480 to 4096x3096.

This is the top level, as per the original game, and you click on it and it'll zoom the view in...


This is where I've been adding configuration, I'm not sure what size to make this tactical level view, so it renders the terrain square as just a solid colour type for the moment... I've already plans for texturing this and adding coast lines, but I'm working on pure mechanics for now... Too many games rush to add visuals before making it work solidly....

So, I added an XML configuration:


Which lets me set the number of squares to render on this tactical view, and how big these squares are... I then played about





Before settling on quite a large view, to match what was given in the original game:


Now, this level of XML control is also extended into most all parts of the system, so this is more a war game visual representer engine than a game at present... But it works how I want it to.

The next Item I needed were some counters I could throw into the screen... So I went with an icon for Infantry, one for cavalry, and an engineer to help bridge those rivers:


I'm going to be keeping this very simple, and perhaps even may publish the code as a tutorial into using SDL and OpenGL.  Its also aiming to be cross platform, so you will see this on Linux soon.

Wednesday, 18 June 2014

WarThunder - Cross Platform - Linux

I had posted, and had been enquiring over with Gaijin, about how or when the current Test OpenGL Renderer will be shuffled out their fun factory doors to give us WarThunder on Linux...

Well, Gaijin demonstrated WarThunder on Linux at this years e3!


I think this is a very exciting development for Gaming on Linux & Gaijin, and am very interested in where they go with this.

Sunday, 8 June 2014

WarThunder - Douche Bags, Frame Drops and Realistic Battles

The new graphics card has arrived, so expect some game-play footage of my Realistic battles from WarThunder very soon....

Last night I actually played a few battled in WarThunder, I found a few bugs too, especially in the OpenGL Renderer.  Before I install the new card tonight I'm going to take my old settings & DxDiag info to send off to Gaijin, then install the new card and see if the same graphical bugs show up.

The reason being that the OpenGL hardware implementation on the the old cards was 2.2 and 3.2 respectively, and both showed the problems, and the new OpenGL implementation is 4.2 (maybe higher if I patch it).

Anyway, I played a good 5 realistic air battled, unlocked the P47D and flew it out... You know what its a decent aircraft, what I immediately noticed was the stock ammo load out sets aircraft on fire fast... The mission contained a set of 3 spotter AI, I took 2 of them down with high deflection shots, setting them on fire.

I then swooped down on two AI HE111's and a player 109, the player I tore up and both AI Bombers too... Over the enemy airfield I then got shot down by AAA.

The next flight out, I met perhaps the biggest douche ever in WarThunder.  He was in a Beaufighter, I'm in my P47... And he's after ground kills, I figured he had rockets and could knock out the pillboxes... No....

No he was just farming the ground targets, so when I saw him break and destroy a couple but take AAA fire, I dove into the mix and shot up a couple of AAA emplacements... Next thing I know he crosses my tail and shoots me with his MG's...

I wondered for a moment whether this was a mistake...

Then messaged... "The word you're looking for is "Sorry", you dick head"...

His reply... "no"...

No he wasn't sorry, he shot me for shooting "his" ground targets... So he was not contributing to the battle, he was just farming credits & XP... The mission was not won by killing the ground targets, indeed, I won the mission killing the last player and last AI air target, as well as emptying my guns into the AI spotted plane mission objective... 

And I was on my way back to the airfield, still with the only battle damage from that moron, when the ticker ran dry.

What annoyed me though was this douche got rewarded for being a douche, he got anti-mech, and "mission maker"... so he got 18 ground kills, but got them through duplicity and aggression towards friendly aircraft.  It stank to high heaven.

I reported the moron, and when I have the new card installed I may fire up and record the replay for my retard videos on YouTube...

This guy left a sour taste in my mouth, so I switched to playing a ground battle, going into a mixed air and ground battle with the Germans... GOD THE LAG!... The ground forces played okay on this same machine with the same settings, but adding the air and ground I got at most 10FPS, and red indications all the time on the frame rate.

Clearly, my rig can't play combined arms fights, so I need this upgrade.

Monday, 2 June 2014

Clean PC & OpenGL

Its been a long weekend, and a hard weekend, I've been doing a lot of code over the weekend, moving an important project from a most defiantly developmental footing to a much more mature footing.

But I've also been and finally had the car sorted, the clutch was never right after the last fixes it had, I've had a new clutch fitted, then was told to fit a new clutch cable, which I did; but still the drive was not right.  When I went to pick the car up a very sheepish mechanic said "Its only £30 for a new pressure plate and oil".. okay... Cool... Two days of labour, £30... What gives... Yes, it'd had a whole other new clutch...

It drives sweet as a nut now, but it does make me wonder how crap was the other clutch, it lasted from October 2013 to June 2014.  I mean, I know after market clutches are cheap tack, but this took the Michael it really did.

Anyway, that all done I was wired late last night, so decided with the project above delivered for feedback I could take some time to service my main PC.  It had been a little battered over time... 


And the first thing I did was give the whole brushed aluminium case a good clean, the fins at the top the grills on the front and the dust mesh points at the bottom over the air in takes.

Then I opened it up and cleaned the case fans, now as you can see I fitted them in 2011, so that's just shy of 3 years service.  They were dusty, but not terribly so.  A quick wipe was all they needed, the rear of the case also just a quick wipe.

The most dust was concentrated in the graphics card, and around the CoolMaster plastic funnel which has its own mesh dust cover, this was sodden with dust and I soon had the card out and dusted it clean before refitting.

My other task was to clean the Corsair Airflow...


Now, this thing had been making a lot of noise, and when I disconnected it and brought it out into the mid-night light bulb glow it was utterly ditched.  Large foamy dust bunnies had formed on all the stanchions and as the whole machine is side mounted the upper sides of the support legs were thick with fir...

Really strange, considering that this is not the main cooler and that there's filtered grills all around this unit... But then it dawned on me, I connect this to the power fan header on the motherboard, and the Q-Fan profile does not include that header.  So this is the only fan set in the machine NOT being speed controlled against performance/heat.  So it was going to be noisy because of the small size of the fans.

Adding in the dust only added to the noise/turbulence.

Cleaned up and refitted tightly however and it is a lot quieter.  My Ram of course is also now being cooled better.

One other thing I'm taking a look at is how OpenGL performs from the libraries shipped with MinGW on CodeBlocks for windows:


From the project menu you can easily create a Test OpenGL project and build it... I assume its running in Mesa/Software... But it runs...


Aside from this, I have Wednesdays Post for the Virtual CPU project done, it was actually written last week, but I've had some problems uploading the two videos for it to YouTube.  I hope with the machine tuned up to upload them this evening.  Even if the videos are not present, the post is scheduled to go... And it covers Interrupts.

Friday, 30 May 2014

WarThunder - OpenGL Performance Discussed

In the final of my series regarding WarThunder this week, I've taken a look at the performance of the OpenGL rendering options.

I've tried this on two machines, with different graphics cards, but very similar specifications otherwise, the two machines are:

Core i7 - 950 - 3.07Ghz
16GB 1600Mhz DDR3 RAM
NVidia GeForce 260 GTX 896MB DDR3

Core i7 - 3770 - 3.01Ghz
8GB 1600Mhz DDR3 RAM
Nvidia GeForce 540 2GB DDR5

Clearly one machine has the superior graphics performance on DirectX mode, yes the 540 out does the 260, just... Though my 260 is a really good superclocked edition, so much so its proving hard to find an economical replacement (pushing me to have to buy a 770 GTX just to see a significant improvement).

Most all the screen shots you see of WarThunder on this blog come from the machine with the 260 in it as well.

But so far all the screen shots have been from the Direct3D renderer.

Now, however I'm testing the OpenGL renderer, the option is listed as Test and I've also tried to collaborate my observations with other players... My overall impression is:

Half the FPS, if I got 60fps in a situation in a plane in Direct3D, I'd get 30 in the near same situation in OpenGL.  This is a rough and ready measurement taken by eye from the FPS reading given on screen in the client.

I've purposefully NOT recorded my game play, I've not run other programs nor over reached things - that is I've not thrown clouds of AI aircraft into formation within a custom battle and flown through them.  I've stuck to playing the regular game in the regular way.

Lets take a look at some screen shots:




It looks the same, I've not noticed any surface level differences, the game looks just as good.

Only when one scrutinizes things do you find the differences, if we jump into a cockpit and look around, we can see where in Direct3D we'd get smooth textures things can look quite odd:


This is the seat over my pilot's left shoulder in the Fw190 A1, as you can see there's this square stippling going on, also along the window rail you can see a darker indication that is actually a shadow from the wind shield surround.

This isn't the only odd thing noted, in the 540 card, not on the 260, I took the Fw190 into a twilight flight.  You can change this yourself in your settings under the Graphics options you need to select the Texture type of "Night as Day" (or something like that)...

When I flew the plane out on the 540 GTX, I saw this strange halow effect around the periphery:


The effect persisted against the clouds, from any angle, or against the ground.  But it did not show against clear sky.


Switching back to Direct3D no such halow was present on either card's output.

Performance wise I've already mentioned the lower frame rate, however, at one point during a pursuit in Historical battle in the Me410 I took out an enemy aircraft, with the explosion close I suddenly had a frame rate reduction down to 2FPS.  Literally slide show mode...

I used a little back stick to bring my nose up and came through it, but I'd moved around 1km before the frame rate returned to above 20 and allowed me to have some semblance of control.

I checked my logging, there was no hard drive activity, no appreciable network lag, no dropped packets, I could type into the client and ask "Anyone else getting lag", which was a reply of "nope" from a fair few players.  Yet I was at 2FPS 50 meters off of the hard deck struggling.

The optimisation of the Direct3D code being used by Gaijin is really good, they get performance out of my rigs other less intensive, less pretty, games get... So perhaps we can chalk this massive red blot on the performance of the OpenGL implementation to a lack of development/optimisation and of course the code being "Test".

But, one would assume the Mac client is already using OpenGL, are any Mac players out there able to share their thoughts?

Either way it looks promising that OpenGL does work, and this of course leaves us thinking about Linux/SteamOS.

Thursday, 29 May 2014

Is WarThunder coming to Linux?

I've been musing about the future of many of the titles on Steam, and their progress in converting them to Linux; or more specifically the Steam OS.  Valve (the publishers behind Steam) are bit into providing technical talks and information to developers to help assist them in converting titles to OpenGL, so I've taken sometime to look at the games I have on Steam and which ones I'd like to see on Windows.

The first, and most recently played was "WarThunder", and after a little reading and a little looking, I spotted in the launcher the option to use "OpenGL"...


It looks promising therefore that Gaijin are porting the rendering engine to OpenGL, I even went as far as switching to OpenGL an firing up the game, my immediate feedback would be that where I was getting 60FPS+ and even 90 FPS in places, I was suddenly getting an average of 43FPS.  However, the OpenGL rendering is listed as "test" and one would assume its not optimized at all yet.

Performance changes aside it does look like Gaijin could have a Linux operable version soon... I just hope when they fix the annoying team text chat bug soon... What bug is this?  Well, when you crash, or die, you are presented the team chat box; and I often start to type into it information to pass onto my team where I went down, especially if I went down due to enemy fire... You can be midway through typing a message when the screen times out and changes from the view of the opponent who put you down to the "Select a plane" or "Observer" screen... This then re-presents the same (or an identical looking) team chat box, but it has wiped out the input you had just seconds before... This is a bug which has been in the game since I started playing, so it is a very annoying problem and one which either isn't getting reported, or isn't getting noticed and fixed.

Back to Gaijin's development model however, if we search for news or even output regarding their porting to Linux there's little initially to go on, in fact on an unbiased Google search this was the first result.

http://forum.gaijinent.com/index.php?/topic/9346-linux-port/

"At the moment only for Windows. About Mac and Linux we will see in the future."  A comment by a Gaijin Forum Administrator on the 28th July 2012.  So have things changed since then?  The launcher says they have... Pawing through the archives it also appears that OpenGL has been quietly present in the builds since early November 2013.

My question to Gaijin therefore would be, have they been forcing any test clients into OpenGL mode, have they been gathering information, or switching us players to OpenGL to gather rendering information?  Because, it is a setting in a solemn corner of the launcher, but so very important to us Linux-philes, for if they release this game for Linux then I'm down to only three titles needing Windows specifically, I could finally look at just playing their game on a native Linux platform...

Linux is not the first new platform they've targeted with the engine, you can now get the option from the website to download the Mac version of the game client, clearly the Mac version is going to leverage OpenGL, and indeed any Mac based players will be testing the formal OpenGL calls.  Unfortunately that doesn't test for quirks in Linux or Windows with their independent implementations of OpenGL.

Steam OS is also a very new kid on the distro block for Linux, so if they're going to target it surely they're going to also be able to give us tweaks to run it on standard Debian or Ubuntu distro's too.

Excitingly I've spoken to Gaijin, and had a reply from one Alexander Trifonov, his message is short and sweet:


"Linux/SteamOS, please wait a little more and there will be some news"


Thank you for your reply Alexander, we look forward to more news from you soon...


Monday, 28 April 2014

Weekends Ending

I'm not sure whether my weekend actually deserved to contain the word "end", because I didn't stop once, between jet washing, and cooking, shopping and actually coming into the office on Saturday I don't feel rested at all...

I did get to play some Minecraft however - screen shots to follow - and I also began more looking into OpenGL, you can skip back through the blog and see I was working on texture mapping some area and viewing it a few years ago, I never really got to use that as work in the office took me in a different location.

But I'm looking at an OpenGL application to leverage Windows, Linux and MacOS... Possibly even OpenGLES, so the Pi & mobile platforms in the longer run.

I have prepared Wednesdays next post about the Virtual CPU code we're working on, so stay tunes for that...

In the news I noted this article:  http://www.bbc.co.uk/news/entertainment-arts-27187582  

Thursday, 30 January 2014

glfw v3 on Debian/Mint/Ubuntu

Please Subscribe now to help me reach 1000 subs :)
This is a post just for me really, but if it helps others, so be it...

Installing glfw on Linux (Mint/Ubuntu/Debian)... My steps...

sudo apt-get install libx11-dev libgl1-mesa-dev libglu1-mesa-dev -libxrandr-dev libxext-dev
sudo apt-get install cmake xorg-dev

Download glfw code, and extract... Move to that folder...

sudo cmake -G "Unix Makefiles" -DBUILD_SHARED_LIBS=on -DCMAKE_INSTALL_PREFIX=/usr
sudo make
sudo make install

Then lets say we want to build the "boing" example, move to the examples folder with the boing.c file...

gcc -Wall -g -c ./boing.c -o obj/boing.o
g++ -o bin/Boing obj/boing.o -lGLU -lGL -lm -lX11 -lpthread -lXxf86vm -lglfw

So in Code::Blocks, your linker settings look like this for a glfw project:


Thursday, 19 December 2013

Read the Specification 2

I've often chided others for not providing me a clear specification, well today I have to chide myself... bad Xelous... BAD BADDD!!!!... For not reading the specification.

Now, in my defence, it was not my fault... The specification was IMPOSSIBLE to attain, and I made the obvious assumption that the person handing it down to me was not an utter fail-tard, not an unreasonable thing to do... But they did fail and so I failed and I'm BAD.

The problem is a system, a widely used system - with many units floating around - which the company produces is equipped with an nVidia GeForce 7300 graphics card.  And I was tasked with exploring the possibility of using OpenGL on this hardware, and the manual I was handed was for OpenGL 3.3, so I set about creating code for this.

None of the code worked, nothing, nada, zip... I looked up tutorials, I contacted online tutorial writers, I looked through forums, I searched for ways to see if the code was wrong, or failing... Nothing, it was saying it worked and was working... But nothing was being displayed so somewhere something was lying.

Frustrated I resorted to basics... and the most basic level you can get to using a library like OpenGL is... "Are these calls supported"...


The new features in OpenGL 3 require G80, or newer hardware. Thus OpenGL 3.0/3.1/3.2/3.3 is not supported on NV3x, NV4x nor G7x hardware. This means you need one of the following NVIDIA graphics accelerators to use OpenGL 3:

So there you go, my fault I should have looked earlier, my own fault... But the other guy, boy should he have thought about this before passing me a manual.

Tuesday, 10 September 2013

Backwards Play Lists - A YouTube Annoyance

Today I have mostly been doing COM work in the office - yes COM - I hate COM... but enough of that, in my personal time I've also been doing some 2D OpenGL, not sprites either, I've been using real quads to do things, blending them and playing about, I'm thinking about little scrolling game ideas to put my 2D graphics to the test.

I've also come here to rant a touch, because I'm so so sick of people on youtube - and there are dozens of them who do this - not looking at their content, these are people with sometimes swish content, cool intro's, 1000+ views per video - which is good going... but then they do the little things wrong, things like.... They have a play list, and the list is backwards!

What do I mean "Backwards"?... Well lets say its a series of uploads, and they're numbered "Episode 1", then "Episode 2", it'd be freaking nice if they bothered to add them into the play list in that order... I know its probably a real fiddle to remove all the videos from the play list and then re-add them all again, because the YouTube folks don't seem to have spotted this problem themselves.



But to us the viewer, where content is king, having to stop move to the player and click back down the list to find the "next" to play is a fucking ball ache.

Wednesday, 19 September 2012

OpenGL - Gaps between Triangles


A strange problem posed itself to me in Linux last night, infact in OpenGL in general - this problem happened on OSX, Ubuntu, Fedora and Windows Vista for me... Here's the low down...

I've created a simple 3D view contained area in OpenGL



Into this I want to place items, buildings, people whatever... So, I start to define a rectangle, which is going to be a wall...



As you can see, on it I place my text texture, so I can tell left (red) from right (blue) and top (yellow) from bottom (white) to make sure my texture loading and texture coords are correct... But I can see that damn line between the two triangles... Yet I'm using the same vertices for the corners, there should be no gap.

Switching from glBegin(GL_TRIANGLES) to glBegin(GL_QUADS) I can still see a single line between the triangles, so its not my coordinates or triangles... What the heck can it be?

Now, I'm using pretty old OpenGL here, really really old stuff, so for 2012 the information available on the ground is pretty slim, there's alsorts of suggestions out there and no real documentation as to what is causing this...

In desparation I started to play about with the blending settings, to no avail, then I started to play with the smoothing mode:

glEnable(GL_SMOOTH);

glHint(GL_POLYGON_SMOOTH, GL_NICEST);

glEnable(GL_POLYGON_SMOOTH);

glShadeModel(GL_SMOOTH);

glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST);

None of this seemed to work... So I started to play with the multi-sampling...

glEnable(GL_MULTISAMPLE_ARB);

Still no joy....

But.. Disable the smoothing AND enable the multisampling and everything starts to work:



// Set Rendering smoothing
//glEnable(GL_SMOOTH);
//glHint(GL_POLYGON_SMOOTH, GL_NICEST);
//glEnable(GL_POLYGON_SMOOTH);
glShadeModel(GL_SMOOTH);
glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST);
glEnable(GL_MULTISAMPLE_ARB);

I can now start to add brick textures and make my boxes into buildings...