LÖVE

Posted: **Thu Apr 19, 2012 1:36 pm**

Snoopy1611 wrote:Hi, I found the Problem that causes the "ghosting" when a canvas is used.
The default PointStyle seems to be "smooth" but for your "draw only pixels that changed" approach ist is important that exact Pixels are drawn to the canvas and not smooth Points.
So if you add
Code: Select all
love.graphics.setPoint( 1, "rough" )
to your love.load() all shold be good.

Note that setPointStyle does not work, there seems to be a bug with that. viewtopic.php?f=4&t=2846&hilit=setPointStyle

I don't know why the ghosting does not happen for everyone my guess is:
a) Different Default values for PointStyle in diffrerent Löve builds? (unlikely)
b) Different SDL Library or opengl implementation?

If this solution works for everyone I would suggest to drop the "imagedata Hack" and go back to canvas besause it's way faster!

And btw. Technicolour: I löve your Emulator! The Z80 code ist pure genius. The "array of functions" to execute the Opcodes is really cool!

Aha, that would explain a lot. I almost certainly have a different SDL version then most. I'll release a version with the fixed pointstyle this evening and maybe a save-state feature of sorts.

And thanks, when originally writing the Z80 core this was pretty much my first Lua project and I had a lot of syntax help from a friend of mine called Divran, he was the genius who came up with the idea of array of functions O(1), my original plan was an ugly else-if binary tree O(log n)

. The memory map also uses a larger array of function pointers (64K each for read and write). Pretty much every other gameboy emulator uses an if-else stack for the memory map so I was quite happy with that innovation

.

Posted: **Fri Apr 20, 2012 3:07 am**

So i was trying do do some optimations to the emulation but had no success because the gameboy always crashed at some point.
When I set a loop do do nothing to see if this causes the crash I noticed that the speed got a lot better!

It most certanly has something to do with the optimations LuaJIT does, but I can't really say what exactly happens.

When running the "oh.gb" ROM it's now nearly 30% faster, and more importantliy the hude drops in FPS that appeared in some places are gone. For example the part of the "Lady with the flying Star" now runs a lot faster!

The only change ist the for loop that runs from 1 to 1!

Code: Select all

----------------
--Step function excutes a single operation at a time. 
----------------
function Step()
	for i=1,1 do  -- does nothing but brings performance!?!?
		if not Halt then
			Operators[Read(PC)]()
		else
			Cycle = 4
		end
	end           -- does nothing but brings performance!?!?
	TotalCycles = TotalCycles + Cycle

	UpdateTimers()
	UpdateScreen()
	UpdateInterupts()

end

Posted: **Fri Apr 20, 2012 4:12 am**

i'd imagine performance would also be somewhat better if the emulator's code were refactored to get rid of all those globals

i started doing this myself a couple days ago but noticed some of the modules referenced each other and by that point i lost interest lol

Posted: **Fri Apr 20, 2012 8:28 am**

Snoopy1611 wrote:So i was trying do do some optimations to the emulation but had no success because the gameboy always crashed at some point.
When I set a loop do do nothing to see if this causes the crash I noticed that the speed got a lot better!

It most certanly has something to do with the optimations LuaJIT does, but I can't really say what exactly happens.

When running the "oh.gb" ROM it's now nearly 30% faster, and more importantliy the hude drops in FPS that appeared in some places are gone. For example the part of the "Lady with the flying Star" now runs a lot faster!

The only change ist the for loop that runs from 1 to 1!

Woah, that's a pretty awesome find, that's some serious performance increase too! I believe it's because the JIT compiler only compiles bytecode that is in loops, I always asumed that the main while loop was sufficient to JIT compile everything in it, but apparently not. I wonder if there are any other areas where this is an issue.

Xgoff wrote:i'd imagine performance would also be somewhat better if the emulator's code were refactored to get rid of all those globals

i started doing this myself a couple days ago but noticed some of the modules referenced each other and by that point i lost interest lol

Hmm, I did consider making it so all the globals were assigned to locals before the frame, then assigning them back to globals afterwards but I wans't sure if it would've been worth it.

Posted: **Fri Apr 20, 2012 3:57 pm**

Of course I tried the same trick in these 3 Functions:
UpdateTimers()
UpdateScreen()
UpdateInterupts()
but it either made no difference or even got slower!

There must be a reason why there are a lot of tips what to do or not to do to optimize for LuaJIT ;-)

One should always keep in mind that things that are right to do in Lua may not be right for LuaJIT.

Posted: **Sat Apr 21, 2012 9:01 pm**

New version, here are the changes:

Changed pixel style to "rough", all the ghosting issues should thus be fixed.
Added an in-game rom selection menu
Added a work in progress options menu, can only change scale atm.
Vsync (60fps) enabled by default (can be changed in load())
Compatability with non-jit, uses Lua bitwise with non-jit and native bitwise with jit. (thanks SiENcE!!) (The speed difference between JIT and non-JIT is around 10-30x, you'd be well advised to use JIT )
Added colour palettes, will eventually add a neat menu to change colours (colour palettes can be changed in load())
Added Sound Channels 1 & 2
Changed keys around, Z and X are A and B, Return and Backspace are Start and Select. Will add in-game menu to change keys.
Optomisations (thanks Snoopy1611!)

A note about sound. It's not even close to being finished and there's clearly still a few issues with the pitch sweep among other things. In some games it should be almost perfect, in others it can be ear rape. If you have a good ear and would be willing I'd like some feedback regarding what's right and wrong with sound compared to other emulators/ a real dmg.

Posted: **Mon Apr 23, 2012 12:17 pm**

Short video uploaded: http://www.youtube.com/watch?v=A05dIqXF ... e=youtu.be

Posted: **Mon Apr 23, 2012 12:42 pm**

I just took a look at the code.Wonderful work, I'm impressed...
Well, it doesn't work on my computer, seems to be related to OpenGL... (a bug with canvas, according to what i saw)...
Any optiions for me ?

Once again, congratulations

Posted: **Mon Apr 23, 2012 10:39 pm**

Roland_Yonaba wrote:I just took a look at the code.Wonderful work, I'm impressed...
Well, it doesn't work on my computer, seems to be related to OpenGL... (a bug with canvas, according to what i saw)...
Any optiions for me ?

Once again, congratulations

Hey and thanks

. I think your best bet is the modified version that uses ImageData rather than Canvas that SiENcE posted a few pages back. If the Canvas thing is a common issue I'll make the ImageData sollution an option, although I'm not sure how I'll handle the menus.

Posted: **Mon Apr 23, 2012 10:51 pm**

I don't support canvases too, but with the ImageData version I have no more than 6 FPS, so I don't mind if you don't update it

LÖVE

I Love Gameboy

Re: I Love Gameboy

Re: I Love Gameboy

Re: I Love Gameboy

Re: I Love Gameboy

Re: I Love Gameboy

Re: I Love Gameboy

Re: I Love Gameboy

Re: I Love Gameboy

Re: I Love Gameboy

Re: I Love Gameboy