Menu
What's new
By:
Filters

Aristotle's Mudlord & Rice Video

Status
Not open for further replies.
death--droid

death--droid

Active member
Moderator
Thank you very much for you're reply gitech.
I like it when people actually post.

Also I'm looking into some of the stuff in GlideHQ by koolsmokey that where allowed to use :)
 
G

gitech

N64 Artist
YEAY!

Very cool!

Request: Do you think you will be able to impement .DDS/.DXT texture format compatibility like Jabo?

:D ,
Jay
 
death--droid

death--droid

Active member
Moderator
I'll look into it for you. :)

Though i think dds is restricted to directx
EDIT:Just proved myself wrong while i was reading something :)
 
Last edited:
V

vinipsmaker

C/C++ programmer, emacs user
I vote on open alternatives. And sorry, I'm not helping the project, but I will help soon (2~3 months, I think).
 
V

vinipsmaker

C/C++ programmer, emacs user
I think I will help soon, I start learn c programming language by myself and I make a program (130 lines of c code) to resolve equations of first and second degree.
 
Cyberman

Cyberman

Moderator
Moderator
C++ and C

C++ is a super set of C it has it's roots in C.

In fact the early C++ compilers generated C and then compiled the resultant code using a normal C compiler. GNUC/C++ is quite a bit different than that, (that is a long discussion) but has it's roots in those early C++ compiler implementations.

C++ has added complexity (or features) if you choose to use them. Otherwise you can almost use it just like it were C.

And it is quite possible to write the entire plugin in C, however you can't take advantage of any of C++ features, the vast majority of which you don't need at all for the plugin anyways (LOL). The only area where it might come in handy is for simplifying the API for handling textures.
 
V

vinipsmaker

C/C++ programmer, emacs user
Cyberman said:
C++ is a super set of C it has it's roots in C.

In fact the early C++ compilers generated C and then compiled the resultant code using a normal C compiler. GNUC/C++ is quite a bit different than that, (that is a long discussion) but has it's roots in those early C++ compiler implementations.

C++ has added complexity (or features) if you choose to use them. Otherwise you can almost use it just like it were C.

And it is quite possible to write the entire plugin in C, however you can't take advantage of any of C++ features, the vast majority of which you don't need at all for the plugin anyways (LOL). The only area where it might come in handy is for simplifying the API for handling textures.
Click to expand...

I don't know the technical differences between the two, but I know the main difference is C++ is object-oriented programming, and c++ already was called of "C with classes". I know the most of c codes can be compiled as c++ with any change and for the others minor changes are needed. After several searchs I decided learn C before C++. I intend learn allegro, sdl, opengl, ncurses, c++, gtk+ and maybe (probably python, java, php, maybe directx and others) others after I learn C. :linux:

And sorry by my bad english knowledge, I will improve it.
 
K

Kreationz

Emulator Developer
Help backporting Rice's code

This is for Aristole. First I assume you now have full control of Rice's project. I am back porting some of Rice's improvements in the DaedalusX64 (and Daedalus for that matter) since it was originally based on Strmn's code. Most of the issues I'm running into are due to code divergence (Things being moved renamed, etc...) I was wondering if you are a member at SF.net. If so is it okay if I set this up as a project there with an SVN and I will give you admin control of it along with myself and add Strmn as a dev to it. (Yes, he's still involved with Daedalus and DX64) We are still using mostly Strmn's old code. Then the first set of commits will just be each version of Rice's source from the Archives Starting with DaedalusD3D8_Rel2, then the 4.X code and so forth until it is up to date with the 6.1.8 code. This would allow me to more easily compar and contrast each version. I can also then add in Strm's improvements (mostly in the way of performance to the current code.) It would take me a little while to do this, but I think both set's of source code can be more closely unified and improved this way. (We currently do this with the original Daedalus.) If this would be okay let me know. Also since 1964 is open source I'm sure I'll be looking at it eventually to. 99% of the work is done one the N64 emu scene and I'm just try not to have to reinvent the wheel so to speak and just give credit where credit is due.
 
M

Mollymutt

Member
microdev said:
Yes and no. There is a hacked version of GlideHQ that dumps the backgrounds in the way needed to be loaded by normal version of GlideHQ.
Click to expand...

So I won't be able to load them with rice? I've always used Rice, and I'm comfortable with it. I'm in the process of dumping and piecing together all of the backgrounds so Djipi can redo them for his Celda pack. We won't get a 100% pack until those backgrounds can be made to work.
 
Cyberman

Cyberman

Moderator
Moderator
Kreationz said:
If Aristole agrees with my request... Rice might get more feature and a performance boost.
Click to expand...
I asked if people were moving to SF and I didn't get much of a 'thrilled' response about it. I would prefer it be on some place like that. I think it is on some place as one of the people has been making SVN commits (not sure which as my memory is bleah). I have some modifications I would like to put into it, but I've got to first get a tool chain setup for building it (if you can't build a binary for testing ones changes are useless and untested). Unfortunately I am busy between other projects etc. As I said before I am a SF member so ... either way. I would like to see it on SF as well. Because I know how to access the commits there at least :D

Cyb
 
Status
Not open for further replies.

Top