What's new

Bra64 news

ashade

New member
Hello everyone, bra64 is not dead! I got it working on wireframes, but some strange things are happanning... the first one is that the image is flipped upside down... I've tried everything! Look at this:

imagem.jpg


It is Super Mario 64 start screen... does anyone have any idea how to fix this?
 

Tagrineth

Dragony thingy
Well, offhand without knowing how your code works, the only suggestion I can make is a quick flip in the DAC, or something along those lines.
 

euphoria

Emutalk Member
ashade said:
Hello everyone, bra64 is not dead! I got it working on wireframes, but some strange things are happanning... the first one is that the image is flipped upside down... I've tried everything! Look at this:

imagem.jpg


It is Super Mario 64 start screen... does anyone have any idea how to fix this?

Maybe you're using upper left coordinates instead of lower left coords and because of this the image is upside down.
PHP:
(0,0) this is where your origo is
*------*
|      |
|      |
*------*
and here it should be
 
OP
A

ashade

New member
oH YEAH, i corrected this bug!! Look at this:

SUPERMARIO.jpg


the bitmap version:
SUPERMARIO.bmp


I think i have done the most hard part... now it is much easier to complete the plugin...
 

WildSOfT

emu-holic
Nice job, ashade.

But why using PJ64 1.5 beta1 , when there's PJ64 1.5 final?

Anyway, good luck with te progress of the plugin! ;)
 
This looks very good. Maybe after all a good opponent for Jabo and Icepir8! But keep working on it!

A small question: Does it (currently) run fast?
 
well considering its running wireframe its a bit unfair to compare it to fully shaded pologon producing plugins
 

Doomulation

?????????????????????????
Well, it is developed in asm, somewhat at least, so yes it is FAST!!!
Very nice work, ashade! :inlove:
 

tooie

New member
written in asm means nothing .. you can easily have it in asm and slower .. it is the algorithms that are important .. granted if you had all them perfect .. then you can possible re-do some in asm to truely optimize
 
OP
A

ashade

New member
Hey man, writing in assembler really means that the code will be faster than c++, just because assembler has special instructions that c++ doesn't have... I will give you a little example:

when u want to set the bit 3 of a dword in c++, you do it:

n |= 0x8

this code is fast, but not so fast as this one in assembler:

__asm bts n, 3

because assembler has specific functions to set, clear and invert the value of one or more bits...

other goal with assembler is that you work directly with the hardware; the code is written your own way... when u use a high level language, u have to compile the code, and the compiler follow some "standards" to convert from c++ to assembler code. The compiler doesn't think as humans, so it can't avoid putting some slow code, even if it is configured for fast code...
 

icepir8

Moderator
ashade said:
Hey man, writing in assembler really means that the code will be faster than c++, just because assembler has special instructions that c++ doesn't have... I will give you a little example:

when u want to set the bit 3 of a dword in c++, you do it:

n |= 0x8

this code is fast, but not so fast as this one in assembler:

__asm bts n, 3

because assembler has specific functions to set, clear and invert the value of one or more bits...

other goal with assembler is that you work directly with the hardware; the code is written your own way... when u use a high level language, u have to compile the code, and the compiler follow some "standards" to convert from c++ to assembler code. The compiler doesn't think as humans, so it can't avoid putting some slow code, even if it is configured for fast code...

Just because there is a special instruction to do something, it doesn't mean that it is faster. There are a lot of examples of Intel adding special instructions that take more time to execute than the multiple instruction solutions. The set/clear/test bit instructions are one of them.
 

Hacktarux

Emulator Developer
Moderator
ashade said:
Hey man, writing in assembler really means that the code will be faster than c++, just because assembler has special instructions that c++ doesn't have... I will give you a little example:

when u want to set the bit 3 of a dword in c++, you do it:

n |= 0x8

this code is fast, but not so fast as this one in assembler:

__asm bts n, 3

because assembler has specific functions to set, clear and invert the value of one or more bits...

other goal with assembler is that you work directly with the hardware; the code is written your own way... when u use a high level language, u have to compile the code, and the compiler follow some "standards" to convert from c++ to assembler code. The compiler doesn't think as humans, so it can't avoid putting some slow code, even if it is configured for fast code...

If you want to play this game i'll play with you :D
I've checked the OR and BTS opcodes, and guess what, BTS is far slower :
OR mem, imm : 3 cycles
BTS mem, imm : 13 cycles

In some cases, on modern cpu, compiler can be faster than manual optimizations coz it isn't only about which opcodes you choose but also the sequence coz modern cpu can execute several things at the same times and you have to know which part of the cpu is used by which opcode and how many time each part is required... It also affects cache management, it's not as simple as it seems to be...

Finally you can optimize as much as u can your functions but as Tooie said if you don't have the good algorithm with low complexity, it'll be totally useless work. You can have 10x times bigger function and it can still be faster than the short one. And if the program is complex as a gfx plugin, optimizations can required very complex functions that can possibly be hard to do in asm...
 

Top