B-Em

discuss bbc micro and electron emulators (including mame) here!
Coeus
Posts: 2100
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: B-Em

Post by Coeus »

dominicbeesley wrote:
Sun Feb 21, 2021 2:48 pm
tricky wrote:
Sat Feb 20, 2021 8:08 pm
On visual studio having debugging information has no performance cost and I checked the optimisations. The profiler puts 60% in Allegro.
Fair enough. I had the optimisations turned off as I was trying to track down a null pointer and the code reordering was doing my nut.
Indeed I don't think debugging symbols slow down execution, it's more a case that they can make an executable quite a bit larger. On the other hand, like you, I sometimes find trying to step through a program with extensive optimisation rather weird so many environments default to being able to build two versions, one with debugging symbols and little if any optimisation, and the other with optimisations and no debugging symbols. I assume Tricky had enabled debugging symbols but kept optimisation. If not we have to wonder what the optimiser is doing.
dominicbeesley wrote:
Sun Feb 21, 2021 2:48 pm
Good spot on the surface lock. I was wondering whether it would be better building up an off screen bitmap and blitting that instead of working direct with surfaces, would that be sensible?
My reading of the documentation is that this is what locking the bitmap is doing - locking it into CPU memory where we can write the individual pixels with normal memory writes. Not doing this, and using allegro's put_pixel function instead, makes the performance utterly unusable. But there may be some more optimisation possible here and I am open to suggestions. I only know what I have read in the documentation whereas you guys may have a better idea of what is happening behind the scenes.
User avatar
tricky
Posts: 5410
Joined: Tue Jun 21, 2011 9:25 am
Contact:

Re: B-Em

Post by tricky »

For visual studio, the debugging information goes into a separate file .PDB and only the path goes into the exe.
Put pixel would either be lock read+write and then the CPU can change the pixel, or a new area of memory big enough for a single pixel could be created and then the GPU could update the main surface, either way, you wouldn't want to do it much.
In general, I would always choose to work with the thinnest layer between my code and the hardware, but on a phone or desktop OS you are going to have the added layer of a driver.
There have been attempts to give the app more specific control, but this is likely to get in the way of the driver driving the hardware in an optimal way, especially on mobile where there are very diverse hardware platforms.
User avatar
Negative Charge
Posts: 23
Joined: Sat Jan 16, 2021 1:35 pm
Contact:

Re: B-Em

Post by Negative Charge »

Does anyone have a version of the latest B-em with the VGM logging from the 1.4 version ported over? I’ve made an attempt and have it compiling okay under VS2019 but I don’t think I’m calling the log function at the right time as I hear slowdown when multiple channels are playing and sometimes a channel isn’t present at all in the VGM. I’ll keep working at it, but wondered if anyone had already developed a patch? Thanks.
User avatar
Negative Charge
Posts: 23
Joined: Sat Jan 16, 2021 1:35 pm
Contact:

Re: B-Em

Post by Negative Charge »

Negative Charge wrote:
Wed Apr 07, 2021 5:40 pm
Does anyone have a version of the latest B-em with the VGM logging from the 1.4 version ported over? I’ve made an attempt and have it compiling okay under VS2019 but I don’t think I’m calling the log function at the right time as I hear slowdown when multiple channels are playing and sometimes a channel isn’t present at all in the VGM. I’ll keep working at it, but wondered if anyone had already developed a patch? Thanks.
I see Kieran’s posted his patch to include VGM logging, so I’ll give this a try:

https://github.com/kieranhj/b-em/commit ... 9c0fe73ba4
Post Reply

Return to “8-bit acorn emulators”