Forums

I am just in a state of shock. I cannot believe I just built a DLL. For years I wondered how in the heck those things worked and it's nothing but a compiled source file that's organized to be used in other languages. After some trial and error, I was able to build my very first DLL function...

VisualBasic...
Private Declare Function AddTwoNumbers LIB "mydll.dll" (A as Integer, B as Integer) as Integer

C++...
extern _int16 AddTwoNum(_int16 A, _int16 B);

No matter what language I use the function does it's duty. What's also excellent is I can use Assembly-style inline functions within C++ functions and still everything will compile and function properly within the DLL. This technique of calling other DLLs should tremendiously speed up my Visual Basic programs. Not to mention the overhead taken off by using Direct X. I'm...I'm...I can't even type. I'm feeling all jittery...Too excited to contain myself. But, really. I need some feedback more than anything. Does anybody have any comments on the techniques I'm planning to use in future programs I create with Visual Basic?

Chris :o)

Quote

> I am just in a state of shock. I cannot believe I just built a DLL.

Yeah, it's easier than the documentation makes it look. I managed to make a WindowBlinds plugin DLL in about 30 minutes with no prior experience (of making DLLs, that is).

Quote

> For years I wondered how in the heck those things worked and it's nothing but a compiled source file that's organized to be used in other languages.

Or rather, it's the same as an executable except it doesn't have an executable header, it instead has an import table.

Quote

> VisualBasic...
> Private Declare Function AddTwoNumbers LIB "mydll.dll" (A as Integer, B as Integer) as Integer

> C++...
> extern _int16 AddTwoNum(_int16 A, _int16 B);

Delphi...
function AddTwoNumbers(a,b:integer):integer; external 'mydll.dll'

You should really be specifying the import name or index, though.

Quote

> No matter what language I use the function does it's duty.

That's kind of the point of them. Actually, the original reason for them was so Windows 1 could run from a low density floppy disk that also had Dos on it, and leave room for apps and documents - the DLLs contained common code that many programs could reuse.

However, DLLs have downsides. If only one program ever uses them then they're going to just waste memory (less would be required if all of the code was in the exe). If one dll is overwritten by another then problems start. And I personally hate it when a program puts a gazillion dlls into my windowssystem folder.

Quote

> This technique of calling other DLLs should tremendiously speed up my Visual Basic programs.

Ah, yes, VB is runtime-interpreted isn't it? So yes, a C DLL would probably speed things up. As a committed Delphian, I have a proper compiler for my code...

Quote

> I need some feedback more than anything. Does anybody have any comments on the techniques I'm planning to use in future programs I create with Visual Basic?

If you can cook up a general-purpose DLL that will give decent benefits for your programs then go for it. If the speed gains are marginal then you could probably save yourself a lot of effort. You don't really explain what you're going to try and do, though.

Maxim

Quote

> If you can cook up a general-purpose DLL that will give decent benefits for your programs then go for it. If the speed gains are marginal then you could probably save yourself a lot of effort. You don't really explain what you're going to try and do, though.

Well, okay. What I was going to try to do is create an emulator of some sort under Visual Basic. I'd been wanting to do it before but something always held me back. For instance the speed issues of using Basic code or calling Windows API functions. And it's a pain to do simple taks like bit manipulation and detailed data types in Basic because it's, well...Basic. But, with some major help from here, I learned how to do the bit manipulation stuff in C and in pure Assembly. But, Visual Basic doesn't support Assembly or C code because it's, well...Basic. So, I just quit after a while and went on learning some other stuff (like SMS/Sega Game 1000 specific stuff). Along my learning curve I discovered scrolling and some other neat features that I didn't understand how to do before (sound waves, graphics blitting, etc). And now, recently I discovered that Visual Basic supports Direct X Version 7. Well, this takes the speed problem out of Graphics and Sound routines in Visual Basic because with Direct X, all multimedia-type functions will be handled by that and not plain Basic code. So, I was really happy about that. But, now that I learned about DLL's and how to create them it's like, Woah! Because DLL's can be created in my C compiler, I can use C and Assembly style codes, while at the same time call them from Visual Basic. Doing emulation type code is a LOT easier to pull off in C or Assembly versus the simple Basic language. So, I got this huge brainstorm. "Why don't I do a little emulator for Windows with the multimedia code in Direct X and the emulation core and system specific stuff in DLL?" And basically, that's what I'm hoping to do pretty soon. I didn't want to open my "big mouth" like before and declare projects and make promises that I may not keep. Nobody likes a person who says, "Yeah. I'm going to do this. I'm going to do that." and never actually does anything. So I'm trying to get away from that and follow Zoop's and Heilophobe's "1% inspiration, 99% perspiration" or what he got from Einstein. But I dunno. I need to play around with this DLL stuff somemore before I jump the gun and create another dead project. I want to see if I can initialize, clear, and modify variables in memory. If I can do that then I'll see where I can go from there.

Chris :o)

Quote

> However, DLLs have downsides. If only one program ever uses them then they're going to just waste memory (less would be required if all of the code was in the exe). If one dll is overwritten by another then problems start. And I personally hate it when a program puts a gazillion dlls into my windowssystem folder.

of course, they need not reside in windowssystem. they can be placed int the same directory as the executable, or the main application can dynamically load them from any directory.

Quote

> > This technique of calling other DLLs should tremendiously speed up my Visual Basic programs.

> Ah, yes, VB is runtime-interpreted isn't it? So yes, a C DLL would probably speed things up. As a committed Delphian, I have a proper compiler for my code...

The Visual Basic package is a compiler. I think it can tun interpreted within the VB IDE for testing purposes, but will compile into native machine code* (or else how could you make a Visual Basic DLL?)
(*unless I am mistaken and the 'compiled' output is just a VB interpreter with the source code embedded in the exe... but I don't believe this is the case).
You're probably thinking of VBScript, which is an interpreted scripting language used by various microsoft products like IE, Access, and the infamous windows scripting host.

Quote

> > I need some feedback more than anything. Does anybody have any comments on the techniques I'm planning to use in future programs I create with Visual Basic?

(putting my Psychic Degree to the test, I'm reading that Zoop would say: "Find a forum about Visual Basic")

Quote

> If you can cook up a general-purpose DLL that will give decent benefits for your programs then go for it. If the speed gains are marginal then you could probably save yourself a lot of effort. You don't really explain what you're going to try and do, though.

I'm not sure what the advantage of splitting off some functions ina DLL is yet, although maybe that gets cleared up in the next message in the thread...

Quote

> Well, okay. What I was going to try to do is create an emulator of some sort under Visual Basic. I'd been wanting to do it before but something always held me back. For instance the speed issues of using Basic code or calling Windows API functions. And it's a pain to do simple taks like bit manipulation and detailed data types in Basic because it's, well...Basic. But, with some major help from here, I learned how to do the bit manipulation stuff in C and in pure Assembly. But, Visual Basic doesn't support Assembly or C code because it's, well...Basic.

Which begs the question:
Why do you want to use Visual Basic at all, when you could use C?

Quote

> So, I just quit after a while and went on learning some other stuff (like SMS/Sega Game 1000 specific stuff). Along my learning curve I discovered scrolling and some other neat features that I didn't understand how to do before (sound waves, graphics blitting, etc). And now, recently I discovered that Visual Basic supports Direct X Version 7. Well, this takes the speed problem out of Graphics and Sound routines in Visual Basic because with Direct X, all multimedia-type functions will be handled by that and not plain Basic code.

NO!
You don't want to do this stuff in Visual Basic. Yes, the business of interfacing with the sound card and blitting bitmaps to the screen can be done almost as quickly with VB as with C...but actually rendering the screen is going to have to be done by you, since there's nothing in DirectX that will speed that up. You still have to lay out the name table and overlay sprites from the tile data that's decoded on the fly, adjust for raster effects like palette changes, horizontal scrolling updates, and name table changes, and that's where most of the time goes. In addition to being much slower in VB, it's also going to be more difficult in VB.

The sound still will also be slower in VB if you want to generate the complete sound wave output live (instead of loop four squarewaves through directx and setting their pitch and volume). Doing your own generating and mixing is necessary for accurate sound ,especially if you want to support sample playback.

Quote

> So, I was really happy about that. But, now that I learned about DLL's and how to create them it's like, Woah! Because DLL's can be created in my C compiler, I can use C and Assembly style codes, while at the same time call them from Visual Basic. Doing emulation type code is a LOT easier to pull off in C or Assembly versus the simple Basic language. So, I got this huge brainstorm. "Why don't I do a little emulator for Windows with the multimedia code in Direct X and the emulation core and system specific stuff in DLL?" And basically, that's what I'm hoping to do pretty soon.

i guess it's conceivable to ween yourself off of VB by transferring more and more to the C sideof things, but it just seems like more work.

Quote

> Chris :o)

Quote

> > > This technique of calling other DLLs should tremendiously speed up my Visual Basic programs.

> > Ah, yes, VB is runtime-interpreted isn't it? So yes, a C DLL would probably speed things up. As a committed Delphian, I have a proper compiler for my code...

> The Visual Basic package is a compiler. I think it can tun interpreted within the VB IDE for testing purposes, but will compile into native machine code* (or else how could you make a Visual Basic DLL?)

Ah, but to run a VB program you need the 6MB or so of VB runtimes. I was under the impression that VB, like Basic from yesteryear, was interpreted; however, the more recent versions have been moving towards semi-compilation, but still need the runtime DLLs to do the actual work. Delphi, OTOH, is similar to use, except you can do pretty much anything (WinAPI, asm) and the compiled exe works standalaone. Enough of my Delphi zealotism anyway... C is the best way.

Maxim

Quote

> Which begs the question:
> Why do you want to use Visual Basic at all, when you could use C?

2 reasons...
1) Visual Basic requires 0 windows specific code on your part. All you have to do is design an entire window by clicking, typing in properties, etc. I can setup an entire complicated working window without using a single line of code. This saves so much time.

2) The Direct X components and functions are much easier to set up in Visual Basic versus the standard C version.

Quote

> NO!
> You don't want to do this stuff in Visual Basic. Yes, the business of interfacing with the sound card and blitting bitmaps to the screen can be done almost as quickly with VB as with C...but actually rendering the screen is going to have to be done by you, since there's nothing in DirectX that will speed that up. You still have to lay out the name table and overlay sprites from the tile data that's decoded on the fly, adjust for raster effects like palette changes, horizontal scrolling updates, and name table changes, and that's where most of the time goes. In addition to being much slower in VB, it's also going to be more difficult in VB.

Here's where DLL comes in. I'll set up the Direct X components to blit the graphics and handle pallete changes to the screen with plain Visual Basic code. But the rendering, scrolling and all other factors will be done in C and mabye even Assembly if I can get away with it.

Quote

> The sound still will also be slower in VB if you want to generate the complete sound wave output live (instead of loop four squarewaves through directx and setting their pitch and volume). Doing your own generating and mixing is necessary for accurate sound ,especially if you want to support sample playback.

Again, here's where DLL comes in. I'll set up a single channel with Direct X, but the actual mixing and sound wave algorithims will be done in C. All I'm doing, hopefully, is sending/recieving memory data from the DLL so...that should keep things at a nice pace.

Quote

> i guess it's conceivable to ween yourself off of VB by transferring more and more to the C sideof things, but it just seems like more work.

I dunno either. But, it's better to try than not to try at all, eh? I tried using C only with Visual C++ but the overhead with MFC and Windows API code was way too overwhelming for me. I kinda tried the Visual Basic approach but I stopped when I saw how unbelievably slow Visual Basic NES (NES emulator done by Don Jarret). Not to mention Don's Milipede and Centipede emulators were slow as well (Also Pure VB Code).

So I'm hoping that if I do the core emulation with DLL, the rendering with Direct X, and the GUI design with Visual Basic that everything will work out well.

Chris :o)

some feedback more than anything. Does anybody have any comments on the techniques I'm planning to use in future programs I create with Visual Basic?

Lookout for the problems with interfacing between a DLL (written in C/C++) and Visual Basic.. Name mangling is EVIL!

Save up some hair to pull out. :)

Arcade Development Central

Quote

> However, DLLs have downsides. If only one program ever uses them then they're going to just waste memory (less would be required if all of the code was in the exe). If one dll is overwritten by another then problems start. And I personally hate it when a program puts a gazillion dlls into my windowssystem folder.

Another interesting use of DLLs is developing a Cross Platform gaming system.

The main 'exe' file contains the platform specific code, and the DLL (with proper defines) contains the actual game code. The DLL would use routines from the main 'exe' file, and export a few routines (I used an Initialize and a VerticalRetrace function).

This is easy to port to many OSes. For example the Mac has Code Fragments. I think Linux and Amiga Shared libraries would also work. I'm not too sure about either BeOS or QNX RTP.

The main 'exe' needs to be rewritten for each platform, but the DLL code compiles with the addition of a few defines, (and a new project, but the new project should work for new games added to the platform).

I've done this on Windows 95/98/etc, and the Mac.
I did run into problems under OS/2, where the DLL cannot call functions in the main 'exe'. This would be easy to work around by putting all the functions callable from the game DLL in their own DLL, since a DLL can call another DLL..

Anyway... DLLs are pretty cool, and useful (once you get past the idea of using them strictly as routines to a main 'exe').

Saturn Development Central

Quote

> So I'm hoping that if I do the core emulation with DLL, the rendering with Direct X, and the GUI design with Visual Basic that everything will work out well.

So, it's almost like a full sms emulator minus the win32-specific stuff, in VB wrapper to provide access to platform specific things like windowing, menus, DX multimedia components, etc...?

Okay, I'll concede, that's not such a horrible idea after all... if you -really- don't want to learn win32 programming yet. But don't think you can escape from it forever...

Quote

> So, it's almost like a full sms emulator minus the win32-specific stuff, in VB wrapper to provide access to platform specific things like windowing, menus, DX multimedia components, etc...?

Well, i'm still not even aiming at SMS emulation. I'm going to start really slow, in baby steps, and work with the SG1000. That's why I was asking before for information on the early TMS VDP that system uses, it's data output ports, and other neat stuff I should know about. I even tried some Z80 programming for the system to see if I could play some sounds, read from the joystick, etc (to get more familiar and comfortable with the system).

Quote

> Okay, I'll concede, that's not such a horrible idea after all... if you -really- don't want to learn win32 programming yet. But don't think you can escape from it forever...

You an't lying. I damn sure need to learn windows if I'm planning a carrer in computer programming. Also, understanding GUI's and how they work is one of the major factors to programming today. But hell, I figure I'm 17. I'm still in High School. That's what college is for. I'm going to need some professional help in learning windows because it's confusing and damn hard to learn it on your own. Even with the internet and wonderful, intelligent people like you :o)

Chris

Quote

> > So, it's almost like a full sms emulator minus the win32->specific stuff, in VB wrapper to provide access to platform >specific things like windowing, menus, DX multimedia >components, etc...?

> Well, i'm still not even aiming at SMS emulation. I'm going >to start really slow, in baby steps, and work with the SG1000. >That's why I was asking before for information on the early TMS >VDP that system uses, it's data output ports, and other neat >stuff I should know about. I even tried some Z80 programming >for the system to see if I could play some sounds, read from >the joystick, etc (to get more familiar and comfortable with >the system).

> > Okay, I'll concede, that's not such a horrible idea after >all... if you -really- don't want to learn win32 programming >yet. But don't think you can escape from it forever...

> You an't lying. I damn sure need to learn windows if I'm >planning a carrer in computer programming. Also, understanding >GUI's and how they work is one of the major factors to >programming today. But hell, I figure I'm 17. I'm still in >High School. That's what college is for. I'm going to need >some professional help in learning windows because it's >confusing and damn hard to learn it on your own. Even with the >internet and wonderful, intelligent people like you :o)

Compared with emulation, I think win32 api is really easy. I started learning it with 17, too :-)
Just one tip: look at some very simple raw c program which implements just a message loop, then you'll really understand what it's all about. DON'T start with those Visual C++ MFC Assistant created base apps, they are completely incomprehensible. You'll find that direct api programming is much easier than doing it in VB, and that those MFC examples really suck.

BTW, where do you live to learn programming in school? We teach it to our teachers...

Why did Microsoft even come up with MFC if the entire world hates it?

I live where the imperialist pigs lie in sloth and prejudice partually determines a colored man's outcome in life....

j/k

Good old USA in the State of Florida (elections...I'm sick of hearing it. Gore baby, Gore!)

Chris :o)

BasicNES (Don Jarret's emulator written in VB) runs most games at full speed with sound and no frame skip on a p200. Even games that use heavy amounts of bank switching (like Super Mario Bros 3) run fast. The only exception is the new "Extended" v1.1, which seems to have a bug causing it to be slower. The regular v1.1 can run Super Mario Bros at nearly 250fps on a p500. The graphics are perfect or near perfect with most games, although some others seem to have vrom problems.

BasicNES is 100% VB code. No special dlls. It uses gdi for the graphics.

Quote

> > Which begs the question:
> > Why do you want to use Visual Basic at all, when you could use C?

> 2 reasons...
> 1) Visual Basic requires 0 windows specific code on your part. All you have to do is design an entire window by clicking, typing in properties, etc. I can setup an entire complicated working window without using a single line of code. This saves so much time.

> 2) The Direct X components and functions are much easier to set up in Visual Basic versus the standard C version.

> > NO!
> > You don't want to do this stuff in Visual Basic. Yes, the business of interfacing with the sound card and blitting bitmaps to the screen can be done almost as quickly with VB as with C...but actually rendering the screen is going to have to be done by you, since there's nothing in DirectX that will speed that up. You still have to lay out the name table and overlay sprites from the tile data that's decoded on the fly, adjust for raster effects like palette changes, horizontal scrolling updates, and name table changes, and that's where most of the time goes. In addition to being much slower in VB, it's also going to be more difficult in VB.

> Here's where DLL comes in. I'll set up the Direct X components to blit the graphics and handle pallete changes to the screen with plain Visual Basic code. But the rendering, scrolling and all other factors will be done in C and mabye even Assembly if I can get away with it.

> > The sound still will also be slower in VB if you want to generate the complete sound wave output live (instead of loop four squarewaves through directx and setting their pitch and volume). Doing your own generating and mixing is necessary for accurate sound ,especially if you want to support sample playback.

> Again, here's where DLL comes in. I'll set up a single channel with Direct X, but the actual mixing and sound wave algorithims will be done in C. All I'm doing, hopefully, is sending/recieving memory data from the DLL so...that should keep things at a nice pace.

> > i guess it's conceivable to ween yourself off of VB by transferring more and more to the C sideof things, but it just seems like more work.

> I dunno either. But, it's better to try than not to try at all, eh? I tried using C only with Visual C++ but the overhead with MFC and Windows API code was way too overwhelming for me. I kinda tried the Visual Basic approach but I stopped when I saw how unbelievably slow Visual Basic NES (NES emulator done by Don Jarret). Not to mention Don's Milipede and Centipede emulators were slow as well (Also Pure VB Code).

> So I'm hoping that if I do the core emulation with DLL, the rendering with Direct X, and the GUI design with Visual Basic that everything will work out well.

> Chris :o)

Download BasicNES

Author	Message
Consolemu Guest	I'm shocked Posted: Wed Nov 15, 2000 11:37 pm
Consolemu Guest	I am just in a state of shock. I cannot believe I just built a DLL. For years I wondered how in the heck those things worked and it's nothing but a compiled source file that's organized to be used in other languages. After some trial and error, I was able to build my very first DLL function... VisualBasic... Private Declare Function AddTwoNumbers LIB "mydll.dll" (A as Integer, B as Integer) as Integer C++... extern _int16 AddTwoNum(_int16 A, _int16 B); No matter what language I use the function does it's duty. What's also excellent is I can use Assembly-style inline functions within C++ functions and still everything will compile and function properly within the DLL. This technique of calling other DLLs should tremendiously speed up my Visual Basic programs. Not to mention the overhead taken off by using Direct X. I'm...I'm...I can't even type. I'm feeling all jittery...Too excited to contain myself. But, really. I need some feedback more than anything. Does anybody have any comments on the techniques I'm planning to use in future programs I create with Visual Basic? Chris :o)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14751 Location: London	Posted: Thu Nov 16, 2000 12:50 am
	Quote > I am just in a state of shock. I cannot believe I just built a DLL. Yeah, it's easier than the documentation makes it look. I managed to make a WindowBlinds plugin DLL in about 30 minutes with no prior experience (of making DLLs, that is). Quote > For years I wondered how in the heck those things worked and it's nothing but a compiled source file that's organized to be used in other languages. Or rather, it's the same as an executable except it doesn't have an executable header, it instead has an import table. Quote > VisualBasic... > Private Declare Function AddTwoNumbers LIB "mydll.dll" (A as Integer, B as Integer) as Integer > C++... > extern _int16 AddTwoNum(_int16 A, _int16 B); Delphi... function AddTwoNumbers(a,b:integer):integer; external 'mydll.dll' You should really be specifying the import name or index, though. Quote > No matter what language I use the function does it's duty. That's kind of the point of them. Actually, the original reason for them was so Windows 1 could run from a low density floppy disk that also had Dos on it, and leave room for apps and documents - the DLLs contained common code that many programs could reuse. However, DLLs have downsides. If only one program ever uses them then they're going to just waste memory (less would be required if all of the code was in the exe). If one dll is overwritten by another then problems start. And I personally hate it when a program puts a gazillion dlls into my windowssystem folder. Quote > This technique of calling other DLLs should tremendiously speed up my Visual Basic programs. Ah, yes, VB is runtime-interpreted isn't it? So yes, a C DLL would probably speed things up. As a committed Delphian, I have a proper compiler for my code... Quote > I need some feedback more than anything. Does anybody have any comments on the techniques I'm planning to use in future programs I create with Visual Basic? If you can cook up a general-purpose DLL that will give decent benefits for your programs then go for it. If the speed gains are marginal then you could probably save yourself a lot of effort. You don't really explain what you're going to try and do, though. Maxim

Consolemu Guest	Posted: Thu Nov 16, 2000 1:40 am
Consolemu Guest	Quote > If you can cook up a general-purpose DLL that will give decent benefits for your programs then go for it. If the speed gains are marginal then you could probably save yourself a lot of effort. You don't really explain what you're going to try and do, though. Well, okay. What I was going to try to do is create an emulator of some sort under Visual Basic. I'd been wanting to do it before but something always held me back. For instance the speed issues of using Basic code or calling Windows API functions. And it's a pain to do simple taks like bit manipulation and detailed data types in Basic because it's, well...Basic. But, with some major help from here, I learned how to do the bit manipulation stuff in C and in pure Assembly. But, Visual Basic doesn't support Assembly or C code because it's, well...Basic. So, I just quit after a while and went on learning some other stuff (like SMS/Sega Game 1000 specific stuff). Along my learning curve I discovered scrolling and some other neat features that I didn't understand how to do before (sound waves, graphics blitting, etc). And now, recently I discovered that Visual Basic supports Direct X Version 7. Well, this takes the speed problem out of Graphics and Sound routines in Visual Basic because with Direct X, all multimedia-type functions will be handled by that and not plain Basic code. So, I was really happy about that. But, now that I learned about DLL's and how to create them it's like, Woah! Because DLL's can be created in my C compiler, I can use C and Assembly style codes, while at the same time call them from Visual Basic. Doing emulation type code is a LOT easier to pull off in C or Assembly versus the simple Basic language. So, I got this huge brainstorm. "Why don't I do a little emulator for Windows with the multimedia code in Direct X and the emulation core and system specific stuff in DLL?" And basically, that's what I'm hoping to do pretty soon. I didn't want to open my "big mouth" like before and declare projects and make promises that I may not keep. Nobody likes a person who says, "Yeah. I'm going to do this. I'm going to do that." and never actually does anything. So I'm trying to get away from that and follow Zoop's and Heilophobe's "1% inspiration, 99% perspiration" or what he got from Einstein. But I dunno. I need to play around with this DLL stuff somemore before I jump the gun and create another dead project. I want to see if I can initialize, clear, and modify variables in memory. If I can do that then I'll see where I can go from there. Chris :o)

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Posted: Thu Nov 16, 2000 7:49 pm
	Quote > However, DLLs have downsides. If only one program ever uses them then they're going to just waste memory (less would be required if all of the code was in the exe). If one dll is overwritten by another then problems start. And I personally hate it when a program puts a gazillion dlls into my windowssystem folder. of course, they need not reside in windowssystem. they can be placed int the same directory as the executable, or the main application can dynamically load them from any directory. Quote > > This technique of calling other DLLs should tremendiously speed up my Visual Basic programs. > Ah, yes, VB is runtime-interpreted isn't it? So yes, a C DLL would probably speed things up. As a committed Delphian, I have a proper compiler for my code... The Visual Basic package is a compiler. I think it can tun interpreted within the VB IDE for testing purposes, but will compile into native machine code* (or else how could you make a Visual Basic DLL?) (*unless I am mistaken and the 'compiled' output is just a VB interpreter with the source code embedded in the exe... but I don't believe this is the case). You're probably thinking of VBScript, which is an interpreted scripting language used by various microsoft products like IE, Access, and the infamous windows scripting host. Quote > > I need some feedback more than anything. Does anybody have any comments on the techniques I'm planning to use in future programs I create with Visual Basic? (putting my Psychic Degree to the test, I'm reading that Zoop would say: "Find a forum about Visual Basic") Quote > If you can cook up a general-purpose DLL that will give decent benefits for your programs then go for it. If the speed gains are marginal then you could probably save yourself a lot of effort. You don't really explain what you're going to try and do, though. I'm not sure what the advantage of splitting off some functions ina DLL is yet, although maybe that gets cleared up in the next message in the thread...

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Posted: Thu Nov 16, 2000 8:41 pm
	Quote > Well, okay. What I was going to try to do is create an emulator of some sort under Visual Basic. I'd been wanting to do it before but something always held me back. For instance the speed issues of using Basic code or calling Windows API functions. And it's a pain to do simple taks like bit manipulation and detailed data types in Basic because it's, well...Basic. But, with some major help from here, I learned how to do the bit manipulation stuff in C and in pure Assembly. But, Visual Basic doesn't support Assembly or C code because it's, well...Basic. Which begs the question: Why do you want to use Visual Basic at all, when you could use C? Quote > So, I just quit after a while and went on learning some other stuff (like SMS/Sega Game 1000 specific stuff). Along my learning curve I discovered scrolling and some other neat features that I didn't understand how to do before (sound waves, graphics blitting, etc). And now, recently I discovered that Visual Basic supports Direct X Version 7. Well, this takes the speed problem out of Graphics and Sound routines in Visual Basic because with Direct X, all multimedia-type functions will be handled by that and not plain Basic code. NO! You don't want to do this stuff in Visual Basic. Yes, the business of interfacing with the sound card and blitting bitmaps to the screen can be done almost as quickly with VB as with C...but actually rendering the screen is going to have to be done by you, since there's nothing in DirectX that will speed that up. You still have to lay out the name table and overlay sprites from the tile data that's decoded on the fly, adjust for raster effects like palette changes, horizontal scrolling updates, and name table changes, and that's where most of the time goes. In addition to being much slower in VB, it's also going to be more difficult in VB. The sound still will also be slower in VB if you want to generate the complete sound wave output live (instead of loop four squarewaves through directx and setting their pitch and volume). Doing your own generating and mixing is necessary for accurate sound ,especially if you want to support sample playback. Quote > So, I was really happy about that. But, now that I learned about DLL's and how to create them it's like, Woah! Because DLL's can be created in my C compiler, I can use C and Assembly style codes, while at the same time call them from Visual Basic. Doing emulation type code is a LOT easier to pull off in C or Assembly versus the simple Basic language. So, I got this huge brainstorm. "Why don't I do a little emulator for Windows with the multimedia code in Direct X and the emulation core and system specific stuff in DLL?" And basically, that's what I'm hoping to do pretty soon. i guess it's conceivable to ween yourself off of VB by transferring more and more to the C sideof things, but it just seems like more work. Quote > Chris :o)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14751 Location: London	Re: OT: VB Posted: Thu Nov 16, 2000 8:59 pm
	Quote > > > This technique of calling other DLLs should tremendiously speed up my Visual Basic programs. > > Ah, yes, VB is runtime-interpreted isn't it? So yes, a C DLL would probably speed things up. As a committed Delphian, I have a proper compiler for my code... > The Visual Basic package is a compiler. I think it can tun interpreted within the VB IDE for testing purposes, but will compile into native machine code* (or else how could you make a Visual Basic DLL?) Ah, but to run a VB program you need the 6MB or so of VB runtimes. I was under the impression that VB, like Basic from yesteryear, was interpreted; however, the more recent versions have been moving towards semi-compilation, but still need the runtime DLLs to do the actual work. Delphi, OTOH, is similar to use, except you can do pretty much anything (WinAPI, asm) and the compiled exe works standalaone. Enough of my Delphi zealotism anyway... C is the best way. Maxim

Consolemu Guest	Posted: Thu Nov 16, 2000 10:00 pm
Consolemu Guest	Quote > Which begs the question: > Why do you want to use Visual Basic at all, when you could use C? 2 reasons... 1) Visual Basic requires 0 windows specific code on your part. All you have to do is design an entire window by clicking, typing in properties, etc. I can setup an entire complicated working window without using a single line of code. This saves so much time. 2) The Direct X components and functions are much easier to set up in Visual Basic versus the standard C version. Quote > NO! > You don't want to do this stuff in Visual Basic. Yes, the business of interfacing with the sound card and blitting bitmaps to the screen can be done almost as quickly with VB as with C...but actually rendering the screen is going to have to be done by you, since there's nothing in DirectX that will speed that up. You still have to lay out the name table and overlay sprites from the tile data that's decoded on the fly, adjust for raster effects like palette changes, horizontal scrolling updates, and name table changes, and that's where most of the time goes. In addition to being much slower in VB, it's also going to be more difficult in VB. Here's where DLL comes in. I'll set up the Direct X components to blit the graphics and handle pallete changes to the screen with plain Visual Basic code. But the rendering, scrolling and all other factors will be done in C and mabye even Assembly if I can get away with it. Quote > The sound still will also be slower in VB if you want to generate the complete sound wave output live (instead of loop four squarewaves through directx and setting their pitch and volume). Doing your own generating and mixing is necessary for accurate sound ,especially if you want to support sample playback. Again, here's where DLL comes in. I'll set up a single channel with Direct X, but the actual mixing and sound wave algorithims will be done in C. All I'm doing, hopefully, is sending/recieving memory data from the DLL so...that should keep things at a nice pace. Quote > i guess it's conceivable to ween yourself off of VB by transferring more and more to the C sideof things, but it just seems like more work. I dunno either. But, it's better to try than not to try at all, eh? I tried using C only with Visual C++ but the overhead with MFC and Windows API code was way too overwhelming for me. I kinda tried the Visual Basic approach but I stopped when I saw how unbelievably slow Visual Basic NES (NES emulator done by Don Jarret). Not to mention Don's Milipede and Centipede emulators were slow as well (Also Pure VB Code). So I'm hoping that if I do the core emulation with DLL, the rendering with Direct X, and the GUI design with Visual Basic that everything will work out well. Chris :o)

cdoty Joined: 29 Jun 1999 Posts: 68 Location: Houston TX	Posted: Thu Nov 16, 2000 10:21 pm
cdoty Joined: 29 Jun 1999 Posts: 68 Location: Houston TX	some feedback more than anything. Does anybody have any comments on the techniques I'm planning to use in future programs I create with Visual Basic? Lookout for the problems with interfacing between a DLL (written in C/C++) and Visual Basic.. Name mangling is EVIL! Save up some hair to pull out. :) Arcade Development Central

cdoty Joined: 29 Jun 1999 Posts: 68 Location: Houston TX	Posted: Thu Nov 16, 2000 10:46 pm
cdoty Joined: 29 Jun 1999 Posts: 68 Location: Houston TX	Quote > However, DLLs have downsides. If only one program ever uses them then they're going to just waste memory (less would be required if all of the code was in the exe). If one dll is overwritten by another then problems start. And I personally hate it when a program puts a gazillion dlls into my windowssystem folder. Another interesting use of DLLs is developing a Cross Platform gaming system. The main 'exe' file contains the platform specific code, and the DLL (with proper defines) contains the actual game code. The DLL would use routines from the main 'exe' file, and export a few routines (I used an Initialize and a VerticalRetrace function). This is easy to port to many OSes. For example the Mac has Code Fragments. I think Linux and Amiga Shared libraries would also work. I'm not too sure about either BeOS or QNX RTP. The main 'exe' needs to be rewritten for each platform, but the DLL code compiles with the addition of a few defines, (and a new project, but the new project should work for new games added to the platform). I've done this on Windows 95/98/etc, and the Mac. I did run into problems under OS/2, where the DLL cannot call functions in the main 'exe'. This would be easy to work around by putting all the functions callable from the game DLL in their own DLL, since a DLL can call another DLL.. Anyway... DLLs are pretty cool, and useful (once you get past the idea of using them strictly as routines to a main 'exe'). Saturn Development Central

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Posted: Fri Nov 17, 2000 11:56 pm
	Quote > So I'm hoping that if I do the core emulation with DLL, the rendering with Direct X, and the GUI design with Visual Basic that everything will work out well. So, it's almost like a full sms emulator minus the win32-specific stuff, in VB wrapper to provide access to platform specific things like windowing, menus, DX multimedia components, etc...? Okay, I'll concede, that's not such a horrible idea after all... if you -really- don't want to learn win32 programming yet. But don't think you can escape from it forever...

Consolemu Guest	Posted: Sat Nov 18, 2000 1:12 am
Consolemu Guest	Quote > So, it's almost like a full sms emulator minus the win32-specific stuff, in VB wrapper to provide access to platform specific things like windowing, menus, DX multimedia components, etc...? Well, i'm still not even aiming at SMS emulation. I'm going to start really slow, in baby steps, and work with the SG1000. That's why I was asking before for information on the early TMS VDP that system uses, it's data output ports, and other neat stuff I should know about. I even tried some Z80 programming for the system to see if I could play some sounds, read from the joystick, etc (to get more familiar and comfortable with the system). Quote > Okay, I'll concede, that's not such a horrible idea after all... if you -really- don't want to learn win32 programming yet. But don't think you can escape from it forever... You an't lying. I damn sure need to learn windows if I'm planning a carrer in computer programming. Also, understanding GUI's and how they work is one of the major factors to programming today. But hell, I figure I'm 17. I'm still in High School. That's what college is for. I'm going to need some professional help in learning windows because it's confusing and damn hard to learn it on your own. Even with the internet and wonderful, intelligent people like you :o) Chris

Pius II Guest	Posted: Sun Nov 19, 2000 5:08 pm
Pius II Guest	Quote > > So, it's almost like a full sms emulator minus the win32->specific stuff, in VB wrapper to provide access to platform >specific things like windowing, menus, DX multimedia >components, etc...? > Well, i'm still not even aiming at SMS emulation. I'm going >to start really slow, in baby steps, and work with the SG1000. >That's why I was asking before for information on the early TMS >VDP that system uses, it's data output ports, and other neat >stuff I should know about. I even tried some Z80 programming >for the system to see if I could play some sounds, read from >the joystick, etc (to get more familiar and comfortable with >the system). > > Okay, I'll concede, that's not such a horrible idea after >all... if you -really- don't want to learn win32 programming >yet. But don't think you can escape from it forever... > You an't lying. I damn sure need to learn windows if I'm >planning a carrer in computer programming. Also, understanding >GUI's and how they work is one of the major factors to >programming today. But hell, I figure I'm 17. I'm still in >High School. That's what college is for. I'm going to need >some professional help in learning windows because it's >confusing and damn hard to learn it on your own. Even with the >internet and wonderful, intelligent people like you :o) Compared with emulation, I think win32 api is really easy. I started learning it with 17, too :-) Just one tip: look at some very simple raw c program which implements just a message loop, then you'll really understand what it's all about. DON'T start with those Visual C++ MFC Assistant created base apps, they are completely incomprehensible. You'll find that direct api programming is much easier than doing it in VB, and that those MFC examples really suck. BTW, where do you live to learn programming in school? We teach it to our teachers...

Consolemu Guest	Posted: Sun Nov 19, 2000 6:37 pm
Consolemu Guest	Why did Microsoft even come up with MFC if the entire world hates it? I live where the imperialist pigs lie in sloth and prejudice partually determines a colored man's outcome in life.... j/k Good old USA in the State of Florida (elections...I'm sick of hearing it. Gore baby, Gore!) Chris :o)

David Finch Guest	Posted: Sat Jan 13, 2001 9:04 pm
David Finch Guest	BasicNES (Don Jarret's emulator written in VB) runs most games at full speed with sound and no frame skip on a p200. Even games that use heavy amounts of bank switching (like Super Mario Bros 3) run fast. The only exception is the new "Extended" v1.1, which seems to have a bug causing it to be slower. The regular v1.1 can run Super Mario Bros at nearly 250fps on a p500. The graphics are perfect or near perfect with most games, although some others seem to have vrom problems. BasicNES is 100% VB code. No special dlls. It uses gdi for the graphics. Quote > > Which begs the question: > > Why do you want to use Visual Basic at all, when you could use C? > 2 reasons... > 1) Visual Basic requires 0 windows specific code on your part. All you have to do is design an entire window by clicking, typing in properties, etc. I can setup an entire complicated working window without using a single line of code. This saves so much time. > 2) The Direct X components and functions are much easier to set up in Visual Basic versus the standard C version. > > NO! > > You don't want to do this stuff in Visual Basic. Yes, the business of interfacing with the sound card and blitting bitmaps to the screen can be done almost as quickly with VB as with C...but actually rendering the screen is going to have to be done by you, since there's nothing in DirectX that will speed that up. You still have to lay out the name table and overlay sprites from the tile data that's decoded on the fly, adjust for raster effects like palette changes, horizontal scrolling updates, and name table changes, and that's where most of the time goes. In addition to being much slower in VB, it's also going to be more difficult in VB. > Here's where DLL comes in. I'll set up the Direct X components to blit the graphics and handle pallete changes to the screen with plain Visual Basic code. But the rendering, scrolling and all other factors will be done in C and mabye even Assembly if I can get away with it. > > The sound still will also be slower in VB if you want to generate the complete sound wave output live (instead of loop four squarewaves through directx and setting their pitch and volume). Doing your own generating and mixing is necessary for accurate sound ,especially if you want to support sample playback. > Again, here's where DLL comes in. I'll set up a single channel with Direct X, but the actual mixing and sound wave algorithims will be done in C. All I'm doing, hopefully, is sending/recieving memory data from the DLL so...that should keep things at a nice pace. > > i guess it's conceivable to ween yourself off of VB by transferring more and more to the C sideof things, but it just seems like more work. > I dunno either. But, it's better to try than not to try at all, eh? I tried using C only with Visual C++ but the overhead with MFC and Windows API code was way too overwhelming for me. I kinda tried the Visual Basic approach but I stopped when I saw how unbelievably slow Visual Basic NES (NES emulator done by Don Jarret). Not to mention Don's Milipede and Centipede emulators were slow as well (Also Pure VB Code). > So I'm hoping that if I do the core emulation with DLL, the rendering with Direct X, and the GUI design with Visual Basic that everything will work out well. > Chris :o) Download BasicNES

Forums

View topic - I'm shocked