Elysian Door - NARAKA [WIP]

A place for people with an interest in developing new shmups.
User avatar
nasty_wolverine
Posts: 1371
Joined: Sun Oct 09, 2011 11:44 pm

Re: Elysian Door - NARAKA [WIP]

Post by nasty_wolverine »

BPzeBanshee wrote:Woohoo! TATE works! Unfortunately I just discovered that the fullscreen toggle seems to lock me into fullscreen rather than go into Windowed mode. It does *something* but it just seems to flicker in and out. Odd. Scanlines definitely work too and look beautiful.
I figured out why this is happening, and happens mostly with vsync off. its because of the way i am capturing change events.
BPzeBanshee wrote: Furthermore, I think I'm definitely having some kind of performance issue happening. When TATEd I find the game slows down when I use a bomb. :(
I cant replicate this at all. apart from the vsync off jitteryness, i dont see any slowdown. however i ll try running it on different system and see if it happens.
BPzeBanshee wrote: On the bright side though, the jitteryness I was having turned out to be from whatever timer system you've got in place (or at least I think it's that), because turning vsync on made it run quite smoothly apart from feeling a little bit laggy in input.

Code: Select all

void state_manager::run()
{	
	int loop = 0;
	this->timer.start_timer();	
	
	while(this->accumulator >= this->deltatime) //deltatime set at 16
	{//update block		
		//16.6667 = 1000 ms / 60 framepersecond | approx 16ms per frame, 62 FPS
		this->accumulator -= this->deltatime;		
		loop++;
		if(loop <= 1) //MAX 1 update per pass
		{
			this->bin->clear();
			this->input->update(); //get frame input for game objects
			state_stack.top()->hash();
			state_stack.top()->collision();	
			state_stack.top()->update();
			state_stack.top()->hudupdate();			
		}
	}

	{//render block
		this->display->clear_screen();
		
		//draw back marquee		
		this->drawmarquee();		

		//game render block
		this->renderer->set_camera(this->state_stack.top()->cam.position);
		this->renderer->set_camera(vector2df(this->state_stack.top()->cam.slider.var, 0.0f));
		this->state_stack.top()->render();
		this->renderer->reset_camera();//resets camera
		this->state_stack.top()->hudrender();
		this->renderer->reset_camera();//resets slider
		
		//draw scanline block
		this->drawscanline();
		//finish
		this->renderer->finalize();
	}

	//this->timer.delay(this->deltatime - this->timer.end_timer()); //sleep in free time, current build has this enabled
	//has different effects at different times, resolution = 2ms, if less than 2ms returns immediately
	this->display->swap_buffers();
	this->accumulator += this->timer.end_timer();
}
That is my update and render cycle. I have been having problems with jitteryness for a while but i am not sure what i am doing wrong. but ideally all inputs for in game stuff is collected at a 16ms interval, so there shouldnt be any difference between vsync on or off. If any one can point me in the right direction, that will be really helpful.
Elysian Door - Naraka (my WIP PC STG) in development hell for the moment
User avatar
nasty_wolverine
Posts: 1371
Joined: Sun Oct 09, 2011 11:44 pm

Re: Elysian Door - NARAKA [WIP]

Post by nasty_wolverine »

So I updated drivers, reset them to default (Nvidia has vsync application dependent by default), tested out with frame limiting and not. with vsync on, everything is smooth, i cant see any slowdown. The jitteryness is still there with vsync off, but i couldnt see any slowdown there too (though the fullscreen/scanline/rotate doesnt work as smooth as i would want).

The jitteryness is actually very advanced screen tearing :(

I need to figure some way out to implement better timing with vsync off.
Elysian Door - Naraka (my WIP PC STG) in development hell for the moment
User avatar
nasty_wolverine
Posts: 1371
Joined: Sun Oct 09, 2011 11:44 pm

Re: Elysian Door - NARAKA [WIP]

Post by nasty_wolverine »

Okay, so as BPzeBanshee had pointed out earlier, the issue was the timer system I was using. Little changes here and there and some trickery good and bad, now my timer system keeps better time than hardware vsync (on my system atleast). There is a bit of screen tearing, but the jitteryness is gone, runs smooth vsync on or off. I will do a write up on how I managed to do it, because i couldnt find much detailed info on net in on single place. Its a frankenstein of a code base :D

On the other hand, still having heap corruption issues with x86 build. Something going wrong in the file extraction and SDL copying, some gl stack over writing, resulting the video output looking like it was passed through a LSD enhancement filter. :mrgreen:
Image


As usual first post updated with current build.
Last edited by nasty_wolverine on Tue Sep 24, 2013 10:48 pm, edited 1 time in total.
Elysian Door - Naraka (my WIP PC STG) in development hell for the moment
User avatar
trap15
Posts: 7835
Joined: Mon Aug 31, 2009 4:13 am
Location: 東京都杉並区
Contact:

Re: Elysian Door - NARAKA [WIP]

Post by trap15 »

nasty_wolverine wrote:now my timer system keeps better time than hardware vsync (on my system atleast)
How is that possible? Additionally, I can't really see any reason to not use vsync, unless you have really low-performing code and prefer people to have tearing AND slowdown/frame dropping.
@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
User avatar
nasty_wolverine
Posts: 1371
Joined: Sun Oct 09, 2011 11:44 pm

Re: Elysian Door - NARAKA [WIP]

Post by nasty_wolverine »

trap15 wrote:
nasty_wolverine wrote:now my timer system keeps better time than hardware vsync (on my system atleast)
How is that possible? Additionally, I can't really see any reason to not use vsync, unless you have really low-performing code and prefer people to have tearing AND slowdown/frame dropping.
Well I couldnt really post saying "Use Vsync or dont play my game!@#$". Either way, if vsync is enabled, it relies on buffer swap, other wise there is some timing code to do some frame limiting to keep a steady 60FPS.

What i meant by
nasty_wolverine wrote:now my timer system keeps better time than hardware vsync (on my system atleast)
is that, with vsync on FPS fluctuates between 59.98 and 60.02 (sometimes going a bit higher), but with vsync off (thats when the limiter kicks in) it shows a steady 60FPS always. I am pretty sure its because of a driver bug or something to do with my card hardware itself.
Elysian Door - Naraka (my WIP PC STG) in development hell for the moment
User avatar
trap15
Posts: 7835
Joined: Mon Aug 31, 2009 4:13 am
Location: 東京都杉並区
Contact:

Re: Elysian Door - NARAKA [WIP]

Post by trap15 »

Or maybe it's because your timer code for the FPS counter and your frame limiter are both CPU-based (and thus limited to the same fidelity), they're actually less accurate than the hardware vsync, which is guaranteed to always be a division of the screen freq.

Do note that 60Hz isn't an integral number of seconds. 1 frame lasts 1000ms/60, which is 16.66 repeating. Thus the precision gets chopped at some point (probably at 16.66 or so). That's why you see 59.98 and 60.02, it's rounding after getting the difference.
@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
User avatar
nasty_wolverine
Posts: 1371
Joined: Sun Oct 09, 2011 11:44 pm

Re: Elysian Door - NARAKA [WIP]

Post by nasty_wolverine »

trap15 wrote:Or maybe it's because your timer code for the FPS counter and your frame limiter are both CPU-based (and thus limited to the same fidelity), they're actually less accurate than the hardware vsync, which is guaranteed to always be a division of the screen freq.
Yes, both are CPU based, and on windows its very hard to get sub-millisecond times accurately with high precision. So what i ended up doing was that each set of 3 frames are at 17, 16, 17 milliseconds. It somehow manages to keep a steady 60FPS. Keep in mind this only happens if vsync is disabled and the game update frequency is set to constant 16ms.
trap15 wrote: Do note that 60Hz isn't an integral number of seconds. 1 frame lasts 1000ms/60, which is 16.66 repeating. Thus the precision gets chopped at some point (probably at 16.66 or so). That's why you see 59.98 and 60.02, it's rounding after getting the difference.
The frame times are collected after the buffer swap and I keep 150 previous samples. if I reduce the number of samples, there is a very high variance, if i increase the samples, there is a slow drifting pattern. Ideally its supposed to be stable over 60FPS +/-0.2 frames. But I am seeing numbers higher than 61FPS at times, which i cant explain if vsync is on.

I tested this with frame times first before putting the FPS display. vsync off mode show steady 16.67ms through out, vsync on mode shows 16.67ms +/- .05ms, both averaged over 150 samples. As I said before, this is the apparent behaviour, and I am not quite sure whats happening below the hood.
Elysian Door - Naraka (my WIP PC STG) in development hell for the moment
User avatar
trap15
Posts: 7835
Joined: Mon Aug 31, 2009 4:13 am
Location: 東京都杉並区
Contact:

Re: Elysian Door - NARAKA [WIP]

Post by trap15 »

I'm just trying to say, it's infinitely more likely that your profiling is broken than your video card's vsync, considering the video output hardware has to generate a valid and precise vsync clock for your monitor to display anything ;)
@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
User avatar
nasty_wolverine
Posts: 1371
Joined: Sun Oct 09, 2011 11:44 pm

Re: Elysian Door - NARAKA [WIP]

Post by nasty_wolverine »

trap15 wrote:I'm just trying to say, it's infinitely more likely that your profiling is broken than your video card's vsync, considering the video output hardware has to generate a valid and precise vsync clock for your monitor to display anything ;)
I more than agree, because timing on windows is such a bitch. timeGetTime with timeBeginPeriod is the most reliable you can get with a precision of ~1-2ms. QPF and QPC can give different readings based on bios, chip manufacturer, which core the thread is executing and the position of the moon in the sky.
AFAIK, on linux/unix you can reliably get upto nanosecond precision with out hassle.

I just didnt exclude the possibility that graphics card vsync is a bit broken coz its a low end one, and has few issues with micro/macro stuttering.
Also, fuck windows, if more people used linux, i would have written the game for linux and only provide arch and slack packages.
Elysian Door - Naraka (my WIP PC STG) in development hell for the moment
User avatar
nasty_wolverine
Posts: 1371
Joined: Sun Oct 09, 2011 11:44 pm

Re: Elysian Door - NARAKA [WIP]

Post by nasty_wolverine »

Exams are over, so back to devving.

Re-writing the renderer from client memory arrays fixed function GL 1.1 to shader and buffer based GL 2.1

So that means I can have DFK level flashiness and bullet mayhem at max rank. no bullet cancelling hyper though.
Also, looking at how to fix the x86 version.
Elysian Door - Naraka (my WIP PC STG) in development hell for the moment
User avatar
BPzeBanshee
Posts: 4859
Joined: Sun Feb 08, 2009 3:59 am

Re: Elysian Door - NARAKA [WIP]

Post by BPzeBanshee »

Re-writing the renderer from client memory arrays fixed function GL 1.1 to shader and buffer based GL 2.1
Do you think there'll be extra compatibility issues with integrated cards as a result of this? I can certainly be a test case for this department if it comes to the crunch.
User avatar
nasty_wolverine
Posts: 1371
Joined: Sun Oct 09, 2011 11:44 pm

Re: Elysian Door - NARAKA [WIP]

Post by nasty_wolverine »

BPzeBanshee wrote:
Re-writing the renderer from client memory arrays fixed function GL 1.1 to shader and buffer based GL 2.1
Do you think there'll be extra compatibility issues with integrated cards as a result of this? I can certainly be a test case for this department if it comes to the crunch.
There shouldnt be. Right now the game request a 2.1 hardware accelerated profile and terminates if it doesnt get one. I was using the gl headers from SDL_opengl.h, which only has 1.1 functions defined. I did migrate it to use glew instead, but the base renderer still used the 1.1 functions. I also researched and found the 2.1 is almost guaranteed to be supported on any kind of card in the last five years atleast.

So, in other words, if the previous versions ran fine, the 2.1 version will run fine too. (hopefully, because there are always those outlier situations.)
Elysian Door - Naraka (my WIP PC STG) in development hell for the moment
User avatar
BPzeBanshee
Posts: 4859
Joined: Sun Feb 08, 2009 3:59 am

Re: Elysian Door - NARAKA [WIP]

Post by BPzeBanshee »

Fair enough. My machine ran this fine apart from the issues I mentioned some time ago so I'll definitely give this a spin next build. :)
User avatar
nasty_wolverine
Posts: 1371
Joined: Sun Oct 09, 2011 11:44 pm

Re: Elysian Door - NARAKA [WIP]

Post by nasty_wolverine »

This got put on hold again for about a month. Death in the family (my dad passed away). Just putting out a status update.

- for starters i got the renderer sorted. full shader based and gpu buffer arrays support, with some nifty optimizations which should give 50% theoritical performance increase. the only thing thats bothering me is should i have support for multiple shaders (only fragment shaders), because i already found easy work aorund for effects in GL 1.1, and can do the same with GL 2.1 with a few extra textures. Do i need the added complexity of runtime shader switching and management?

- Things left to do are text rendering functions and some structs and classes to handle glm matrices easier so that orientations and scale can be fed directly to the renderer and easy to manipulate.

- also, the renderer is fully functional in x86 mode.

On a sidenote, when I played Noah!'s one-two plus the cagar label, I was blown away. and it was made in a year according to him, plus cagar churned out his mix in about a month or so. I have been stuck with this for more than a year now. I really need to get my ass in gear and finish this already.
Elysian Door - Naraka (my WIP PC STG) in development hell for the moment
User avatar
railslave
Posts: 505
Joined: Fri Oct 26, 2012 8:38 pm
Location: Abertillery , South Wales

Re: Elysian Door - NARAKA [WIP]

Post by railslave »

nasty_wolverine wrote:This got put on hold again for about a month. Death in the family (my dad passed away). Just putting out a status update.

- for starters i got the renderer sorted. full shader based and gpu buffer arrays support, with some nifty optimizations which should give 50% theoritical performance increase. the only thing thats bothering me is should i have support for multiple shaders (only fragment shaders), because i already found easy work aorund for effects in GL 1.1, and can do the same with GL 2.1 with a few extra textures. Do i need the added complexity of runtime shader switching and management?

- Things left to do are text rendering functions and some structs and classes to handle glm matrices easier so that orientations and scale can be fed directly to the renderer and easy to manipulate.

- also, the renderer is fully functional in x86 mode.

On a sidenote, when I played Noah!'s one-two plus the cagar label, I was blown away. and it was made in a year according to him, plus cagar churned out his mix in about a month or so. I have been stuck with this for more than a year now. I really need to get my ass in gear and finish this already.
Oh no, sorry to hear that , what a major thing :(
"When I get my hands on some money
I'll kiss it's green skin
And I'll ask it's dirty face
"Where the hell have you been?" - Michael Gira (Swans)
User avatar
BPzeBanshee
Posts: 4859
Joined: Sun Feb 08, 2009 3:59 am

Re: Elysian Door - NARAKA [WIP]

Post by BPzeBanshee »

Too many people dying lately. Don't give in the misery though nasty, stick to it and believe in your power. :)
On a sidenote, when I played Noah!'s one-two plus the cagar label, I was blown away. and it was made in a year according to him, plus cagar churned out his mix in about a month or so. I have been stuck with this for more than a year now. I really need to get my ass in gear and finish this already.
Duke Nukem Forever took 10 years and I'm still waiting for n0rtygames to get his PC port out in the open world instead of the constrained world of XBLIG. Fuck the rest, it will take as long as it takes.
User avatar
nasty_wolverine
Posts: 1371
Joined: Sun Oct 09, 2011 11:44 pm

Re: Elysian Door - NARAKA [WIP]

Post by nasty_wolverine »

Yo, I am back. been out of town for sometime, and finally cleared my exams (got a college degree bro), so now to buckle down on this.

things done:
- I has text rendering
- I has offscreen framebuffer

to do:
- glm handlers, plus tune camera system for using the same
- multiple framebuffers, for layering and lazy composite later (cool aura effects, improve visibility, render stage simplification)

I am gonna stop with the renderer after that, or else i probably never finish the game.
Elysian Door - Naraka (my WIP PC STG) in development hell for the moment
User avatar
nasty_wolverine
Posts: 1371
Joined: Sun Oct 09, 2011 11:44 pm

Re: Elysian Door - NARAKA [WIP]

Post by nasty_wolverine »

nasty_wolverine wrote: - multiple framebuffers, for layering and lazy composite later (cool aura effects, improve visibility, render stage simplification)
got this done after some weird bugs, so its just one framebuffer with multiple texture attachment. I can render things to different textures, and before the final output is shown, they are composited into a final texture with different color, alpha and blend mode (so if you wanted you could make the items, clouds, hud, background whatever semi-invisible from a menu box). expect DFK/CC level flashiness.

now if i can just get the glm handlers done, and shove this renderer into the original code, i can then relax a bit.
Elysian Door - Naraka (my WIP PC STG) in development hell for the moment
User avatar
nasty_wolverine
Posts: 1371
Joined: Sun Oct 09, 2011 11:44 pm

Re: Elysian Door - NARAKA [WIP]

Post by nasty_wolverine »

Image

I lied when i said i was just going to rewrite the rendering engine. Turns out, i re-wrote the whole engine. Better designed with cool new tricks and all.

whats new!!!
- engine uses a much cleaner design (so that i can add lua scripting in the future).
- renderer uses frame buffer stacking.
- more flexible buffer compositor for some sexy effects.
- much better input design (replay function can be added, but later)
- better state and object handling, so its easier to code enemies and stages
- built on mingw, so no additional stuff to install, all necessary libraries can be shipped with the exe.

So, i finished with the base engine a few days back and working on game code. There may be a demo out soon (like a month maybe), but depends on what life throws at me again...
Elysian Door - Naraka (my WIP PC STG) in development hell for the moment
User avatar
BPzeBanshee
Posts: 4859
Joined: Sun Feb 08, 2009 3:59 am

Re: Elysian Door - NARAKA [WIP]

Post by BPzeBanshee »

Image

Sounds like you got yourself a pretty solid base. Looking forward to how it plays out next release. You got the jitteriness and FPS display sorted out some time ago right?
User avatar
nasty_wolverine
Posts: 1371
Joined: Sun Oct 09, 2011 11:44 pm

Re: Elysian Door - NARAKA [WIP]

Post by nasty_wolverine »

BPzeBanshee wrote: Sounds like you got yourself a pretty solid base. Looking forward to how it plays out next release. You got the jitteriness and FPS display sorted out some time ago right?
Well, the base is still under work, but only minor tweaks. Kinda like, all new features on hold except necessary ones, only bugfix and cleanup.

On jitteriness and FPS, let me tell what happens on windows.
Windows doesnt really behave well for realtime apps. The timing is screwy, and it literally pulls the rug from under your feet.

For timing you have access to two different types of function. The first is your timeGetTime method, by default this is of the resolution of 10ms. You can however, set this to be of the resolution closer ~2-3ms, but that is a system wide change, ideally your app should set this on startup and reset the same on exit. then you have your performance counters which is the recommended way to time games on windows, with a resolution of close to few us(microseconds), based on the cpu timer. this is more horrible, as this sometimes drifts and is core dependent, so if your game changes cores, the readout from the performance counters can change. so you never measure anything more than a millisecond with this method.

In opengl, when you finish your scene, you call the swapbuffers for refresh the screen. When vsync is disabled this will run as fast as possible and you get horrible screen tearing. When vsync is enabled its even more horrible. swapbuffers is essentially a busy wait, and windows almost hates anything with busy wait. windows expects apps to use its messaging queue for inputs, which kinda puts a app thread to sleep if there is no input. since a game will usually bypass the event queue, CPU usage hits about 100%. Any app using that much cpu will jitter, because thread scheduler will keep putting your app to sleep to let other threads run. So, ideally you would call Sleep() in your main thread to release some time for other threads to run. but sleep is dangerous. if you ask it to put the app to sleep for 2ms, it will ensure the minimum time is 2ms but the maximum time is OS dependent. So you do a few test run to see whats the minimum time the OS sleep function takes. this needs solid timing, which is unavailable on windows. thats the catch 22.

In the end, you will need a mix and match strategy to keep reasonably good time and low cpu usage on windows. and its a headache. because you are never sure how it will behave on different machines.
Elysian Door - Naraka (my WIP PC STG) in development hell for the moment
User avatar
BPzeBanshee
Posts: 4859
Joined: Sun Feb 08, 2009 3:59 am

Re: Elysian Door - NARAKA [WIP]

Post by BPzeBanshee »

That sounds like quite some shennanigans, thanks for the explanation.

If OpenGL is that bad though, how is it then that other OpenGL apps (for instance ENIGMA, which has the option of OpenGL 1 and 3, or Cannonball) do not present the jitteryness of Elysian Door's last build? Is it a version-specific thing? Am I missing some distinctions here?
User avatar
nasty_wolverine
Posts: 1371
Joined: Sun Oct 09, 2011 11:44 pm

Re: Elysian Door - NARAKA [WIP]

Post by nasty_wolverine »

BPzeBanshee wrote:That sounds like quite some shennanigans, thanks for the explanation.

If OpenGL is that bad though, how is it then that other OpenGL apps (for instance ENIGMA, which has the option of OpenGL 1 and 3, or Cannonball) do not present the jitteryness of Elysian Door's last build? Is it a version-specific thing? Am I missing some distinctions here?
OpenGL has nothing to do with it, since its only a standard. windows general implementation of opengl that is version 1.1 is very outdated (the last builds were reverting to 1.1 builtin version, which is software and included with the OS). So you have to make sure there is a hardware based implementation (meaning a gfx with a driver installed) present. The busy lock on swapbuffers is a minor problem. If i understand correctly the Dx version of swapbuffers employs a thread timer, that puts the thread to sleep till the vsync signal wakes it up again.

The problem was with the way i had implemented the timer. either the program was busy waiting too long causing the OS to pull the rug underneath it, or it was sleeping longer than needed. Now, it uses a hybrid method. it now sleeps for about 70% the idle time, and busy waits the rest 30%. So frame rates are pretty stable. even with out vsync it keeps good (but not great) time.

Also, there is difference in how the game is implemented. if it is frame based, then whenever a frame takes longer than 16.66 ms, it will cause visible stutter, and this is unavoidable. But, if it is time based, and you are factoring in how long the last frame took in your evaluations, then the stutter is minimised, unless its skipping 3-4 frames in a row.

Plus, certain graphics card produces micro-stutters, which is more of a hardware fault than anything. Intel gfx cards have been known for their less than stellar GL performance.

So in the end, stutters in the earlier versions were caused by me less knowledgeable than required.

Apparently, after some research last night, performance counters on windows 7 and above should return constant reads even from different threads. i need to go back and test this. the last time i had checked i was on windows server 2008.

edit: nope still flawed, check comments on the accepted answer http://stackoverflow.com/questions/1739 ... ncecounter
Elysian Door - Naraka (my WIP PC STG) in development hell for the moment
Post Reply