Interview With Rlyeh

[moz]

which other coder do you keep an eye on, i.e. when they release?

 

[rlyeh]

Done.
Any questions out there?

 

[sam fisher]

You watch Vobbo His short time in the scene was pretty good.

 

[K-teto]

I have some questions.

1) Now that you are working for as a professional coder, writting games for NDS, do you expect some lazyness derived from the fact that you are coding for money and what you do for the scene is for free? don't you think that you are losing money coding for free when you get paid for it?

2) How many old (and not so old) machines do you own? can you remember it? wich ones? (you should be proud of your collection)

3)
If a==5
and b==2
c==(a - b)
What's c?

And the most important question.
Will you give me that amiga1200 that i'm pretty sure you turned on 1 or 2 times?
And that MSX2? XD

 

[DaveC]

Rlyeh,

I have used your emus on the Gp32 and I have to say they are in a class all their own. Your work is very professional and it shows that you put alot of effort and time into them. I loved them on the GP32 and can't wait for the day they show up on the GP2X.

I have one question based on the HPL nature of the comming emus. You state that system specific optimizations are not allowed to make the code portable to everything. This will probably be fine for stuff like Speccy or ColecoVision but won't that make the more complex stuff run too slow on the GP2X? For example without using hardware specific functions Megadrive, SNES, PC-Engine, CPS1/CPS2, NeoGeo would just be way too slow to be playable. Even now NES,SNES, PC-Engine stuff has problems running well on the GP2X.

Is their some thing that I don't know of that will take care of the speed issues for the more demanding systems? Is there maybe some module that will use the hardware in the GP2X to overcome the speed issues? How does this work?

Also I was wondering, roughly when do you think some of these emus will be released for the GP2X?

The GP2X joystick has been some controversy on these boards for awhile. Some like it, some hate it, some don't really care either way. Do you like the stick? What do you think of it?

(If you don't like it would you be interested in one of my d-pad mods for free? I would donate the pad and installation service if you wanted it.)

Thanks.

 

[icurafu]

(If you don't like it would you be interested in one of my d-pad mods for free? I would donate the pad and installation service if you wanted it.)

Very kind of you!

Is this your way of ensuring fday doesn't use stick-click for menu options?

 

[rlyeh]

Answered.

K-teto: amiga nop. msx2 might be, but dont sell your gp2x as a deal ;-)
DaveC: thanks for the support. i dont need the mod cap, thanks.

Any other question?

 

[moz]

c==3 (its a bit cold today)

 

[b._.o._.b]

How do you keep focused and motivated to make your projects as polished and complete as they are? Are you very organized, disciplined? Do you have any tools or method to accomplish your tasks?

 

[DaveC]

Answered.

K-teto: amiga nop. msx2 might be, but dont sell your gp2x as a deal ;-)
DaveC: thanks for the support. i dont need the mod cap, thanks.

Any other question?

Actually it isn't just a "cap" it is a complete d-pad that replaces the stick and functions like a regular d-pad like GBA etc. That is fine though.

Speaking of which there are a number of these pads floating around now. Please make sure your emus support software diagonals(almost all other software does now) so all users can enjoy your work. This means that a right +up input would be interpreted as a diagonal just like a normal GBA pad would. There doesn't need to be any option or menu as both input types can be used at the same time and don't effect each other. Also an alternative for the stick push should be given. See below for more info.

http://gp2x.projectinfinity.org.uk/viewpage.php?page_id=16

27. Due to the HPL nature of the comming emus, you state that system specific optimizations are not allowed to make the code portable to everything. This will probably be fine for stuff like Speccy or ColecoVision but won't that make the more complex stuff run too slow on the GP2X?

Probably, although HPL is a matter subject to change yet. We'll see how good or bad it works when porting the emulators. It will be a good exercise to test HPL libraries indeedly.

If it is the case that some emus such as PC-engine or NES run too slow using the generic HPL ports would the source code be released for them? In that case someone could optimise for the GP2X hardware by adding ASM cores, using the blitter, hardware specific speedups/hacks etc. Will this be possible or will the ports be closed source?

 

[rlyeh]

Answered.
Any other question?

---

Also an alternative for the stick push should be given. See below for more info.

does DPAD not feature push at all?

 

[DaveC]

Answered.
Any other question?

---

Also an alternative for the stick push should be given. See below for more info.

does DPAD not feature push at all?

None of the pads support the push. It would be much too difficult to implement and still have the pad handle well. An external switch could be added with not too much work but you can't assume it is there. Evil Dragon has some pad mods (soon) in his shop.

That push switch is bad anyway. It is part of the stick pivot point. Excessive use and/or force using the push wears out the stick and it may get loose and jam when it wears. There have been posts here about sticks breaking that way. If you look at the pic in the link you will see that the push pivots on a tiny piece of black plastic, not very robust. The push can be used but an alternative should be given such as a combo of two buttons etc.

Ports will not be closed source. Anyways, merging specific code with HPL code breaks up HPL physolophy. It's better to stick with pure C in that case.

Won't that make certain emus such as SNES, PC-Engine, Amiga etc. maybe even NES impossible at full speed using HPL? Those *need* some ASM to get full speed on slower devices such as the GP2X. It seems then HPL is geared toward simpler 8-bit system emulation and homebrew is that right?

HPL will be great for those that want to port to everything. For the GP2X community I think many of us would rather have faster emus without having to overclock to the max (some can't even do that very high). Will there be a work around for that?

Do you have any future solutions for those or would such emus just be avoided? Maybe some kind of custom routeen that gets called up depending on the target? Or will the code produced be used as a base and then optimizations made from there on the target system (s)?

 

[rlyeh]

Push button text...

Ok. I was not going to use push button anyways.

HPL will be great for those that want to port to everything. For the GP2X community I think many of us would rather have faster emus without having to overclock to the max (some can't even do that very high). Will there be a work around for that?

Do you have any future solutions for those or would such emus just be avoided? Maybe some kind of custom routeen that gets called up depending on the target? Or will the code produced be used as a base and then optimizations made from there on the target system (s)?

One single source. That's it all. With all what this means (pr0s and c0ns).

If the programmer wants to split up the source code into different (and optimized) versions, he's right to do it. However, portability is not guaranteed in this case (only up to break point).

Anyways, I was thinking about a doing portable ASM optimizations too.


----


More questions?

 

[rlyeh]

Unless someone asks any other question I think this interview is already quite finished
GnoStiC will have to translate a bit

 

[Nova]

One more?



Will fday be coming soon? :unsure:



You're my fave coder btw, seriously, I have spent so many hours playing your emus, especially Fgb