View previous topic - View next topic |
Author |
Message |
ThousandKnives Wandering Minstrel
Joined: 17 May 2003 Posts: 147 Location: Boston
|
Posted: Sun Feb 15, 2004 2:10 pm Post subject: |
[quote] |
|
Happy wrote: | LeoDraco wrote: | Unless you decide to attend a shitty college that does everything in Java, you'll need to know C++ anyway. |
Actually, shitty colleges do everything in Visual Basic. I've looked around the area I'm in and all the colleges teach nothing but Visual Basic. Fie! |
Got damn! I've never heard of any college CS departments using VB. Apparantly you have discovered an entirely new plane of shitty CS departments.
Valerman wrote: | Trust me, assembly IS NOT the language you want to learn, and IF you absolutely have to learn it, go for MSIL ASM, and not x86 - at least if you want to be able to run your programs alright on the next version of Windows. |
Assembly languages ARE extremely specialized. On the other hand, as a learning tool they are very useful, and can be very fun to program in. I know I had a lot of fun in my assembly language class.
Also, assembly languages are similiar enough in principle that learning a new ASM isnt (usually) too hard if you already know one. I can't say the same about re-writing all the code, which can be VERY lengthy.
|
|
Back to top |
|
|
Mandrake elementry school minded asshole
Joined: 28 May 2002 Posts: 1341 Location: GNARR!
|
Posted: Sun Feb 15, 2004 8:41 pm Post subject: |
[quote] |
|
my old college switched everything to VB the semester after I left. Why? becuase MS was funding their software. So every single class taught was switched from Java or C++ to either VB or C#. Bleah!
On Lisp- I love Lisp and want one day to write an extendable Lisp so that you can write game AI's in Lisp....whihc would be fun fun fun fun. But that's a wishfull thinking kind of thing.
Python- well, let me just say as a man who knows a gazillion languages, I love Python. Sure, for speed it's got it's drawbacks, but it's not too shabby (since most people have compies over my minumum which is a 90mhz).....it's portable as they come....and the language itself is a work of art. I've never felt so unrestrained by a programming language before.
Wiring code in it, for me, is second nature. I just write the code and it works.
but enough about this crap. What was this post about again? _________________ "Well, last time I flicked on a lighter, I'm pretty sure I didn't create a black hole."-
Xmark
http://pauljessup.com
|
|
Back to top |
|
|
Nexinarus_lazy Guest
|
Posted: Mon Feb 16, 2004 9:40 am Post subject: |
[quote] |
|
Might have to take your word and learn python and lisp some day for giggles.
And anyway making games for ASM or QB or anything, hmm whatevers fun. Gameplay is not speed intensive often so hey whatever you want is fine i think. NES games are mostly intirely made in ASM and look how they turned out ^_^. But if you want speed and graphics in qb id recommend reading CGI JOE's tutorial for ASM in QB its quite nice (I have this somewhere..). But its nasty, QB is not a fast language. Even simple things like logic are slow in qb. It add's up and if you want speed get a modern speedy compiler like (sadly) C or C++. There are some alternatives for fast compilers though.
Wait I hope i was talking about what we were talking about.. shit..
|
|
Back to top |
|
|
tcaudilllg Dragonmaster
Joined: 20 Jun 2002 Posts: 1731 Location: Cedar Bluff, VA
|
Posted: Wed Jul 14, 2004 5:33 pm Post subject: |
[quote] |
|
I suggest making your game in BASIC but producing it in C. ;) What do I mean by that? Well, BASIC is great for experimentation purposes. It was made by scientists for scientists, to write their lab programs with. It's slow. Very very slow. I mean, seriously, it is slow.
Call ABSOLUTE can help, but alas it is slow, too. The calling part, and the stack switching part, is slow. Critically slow. Your graphics are gonna be slow unless you do almost everything with Call ABSOLUTE. Do not try writing your pixels to memory with BASIC code. It is so slow that you'll be unable to avoid the terminal V-trace tearing over your monitor. *shudder* Do try writing them an entire image at a time, using Call ABSOLUTE assembly to swap integer array elements into a double buffer. Blast this to the video buffer using the same routine. Do math the same way, conducting operations on entire arrays at a time through Call ABSOLUTE, instead for using FOR loops or DO loops. Again, QB45 is critically, terribly slow. Although I'm sure what you want to do is possible, and if you do it, you may become both a legend and the end of the QB45 scene, recognize that C/C++ is so very much a better option for actually producing your game, because the graphics and sound won't be performance issues. Get the engine done in BASIC because the syntax is simple enough for experimentation, then port the engine to C++ for distribution.
To be honest, I think we all need to pitch in and write a fast QB-X that is fast as C and easy as BASIC. :P
|
|
Back to top |
|
|
Joakim Tenshi's Bitch (Peach says "Suck it!")
Joined: 05 Apr 2004 Posts: 64
|
Posted: Wed Jul 14, 2004 8:56 pm Post subject: |
[quote] |
|
I'd do everything in C++, because I could then enjoy the ease of designing in OOP and programming in the fastest language, but even if I was using C, I wouldn't take the time to write my engine in basic first and then C.
Anyways, I agree that a fast BASIC language would be great. In fact, there are serveral of these projects running.
If I was to make one, I'd make it compleatly OOP with single inheritance, preferably convertable to C++ so we could use all the great libraries out there.
I wouldn't keep all the statements from QBASIC, just the vital ones like IF THEN ELSE, WHILE WEND, SELECT CASE, heck, I would probably change the names of some of these statments and convert things like WEND to END WHILE.
If somebody someday wants to work with me on making a OOP BASIC to C++ converter, which would then be compiled with eg. GCC, I think I'd do it :) It won't be as complicated as it might sound (but not easy either)...
|
|
Back to top |
|
|
tcaudilllg Dragonmaster
Joined: 20 Jun 2002 Posts: 1731 Location: Cedar Bluff, VA
|
Posted: Wed Jul 14, 2004 10:48 pm Post subject: |
[quote] |
|
I don't think a BASIC to C++ converter would be even as hard as you think,Joakim. What I'd do is draw up a correspondence chart between code lines in BASIC and equlivent lines in C++, like this:
Code: |
PRINT ---> cout();
DIM Var%(VarLength%) ----> int Var[VarLength];
SUB Procedure (Var%) ----> void Procedure (int Var) {
END SUB/END IF/NEXT/LOOP ----> }
EXIT ----> return;
|
The challenge would be taking a TYPE structure like this and turning it into an inheritance-layered object.
Code: |
TYPE TestType
TestString AS String * 16
END TYPE
TYPE SuperTestType
InheritedString AS TestType
END TYPE
|
Implementing this would be half of an entire OOP infrastructure, as I see it. A good stepping stone for a full interpreter.
DEF SEG references could be turned into temporary pointers. DEF SEG null/0 references would set these pointers back to null, so as to avoid memory leaks. Other statements, like PSET, could be turned to direct VGA writes, and PLAY could be put to FM MIDI, maybe.
To implement the transitioner, first it would be necessary to parse the codes, first into tokens, then into lines. Then each token of each line could be transformed into its C/C++ equivalent with minimal fuss. Again, the problem is the OOP infrastructure. A BASIC-to-C converter might be a better choice at first. The step up to C++ could then be undertaken from the vantage point of an existing foundation.
That said, maybe a BASIC-to-JS converter would be just as useful.
|
|
Back to top |
|
|
Joakim Tenshi's Bitch (Peach says "Suck it!")
Joined: 05 Apr 2004 Posts: 64
|
Posted: Thu Jul 15, 2004 10:20 am Post subject: |
[quote] |
|
Well I wasn't going to make QB for windows. Not even BASIC for windows. I would make a new language with the same feel and most of the syntax from basic, but make it compleatly OOP and not procedural. I wouldn't be aiming on a basic compatible language (look what it did to c++ to be c compatible), I would aim on somthing like this:
Code: | uses strings, integers, output
class mygame ' default anchestor is Object
function create(args as strings.list) ' default function type is void (required for the creator)
object x, y, i as integers.int32
x = 15
y = 20
for i = 1 to args.count
output.print(args(i))
x.inc
end for
end function
end class
|
I would make it fully OOP like Java, and inherit all objects from a class Object. I would probably include a statement like
final object x as integers.int32 to indicate that x could only be integers.int32 and not anything that inherits that type. Maybe find a better name than 'final'.
Functions would probably be public by default and data would be private by default... There are a lot of things to think about.
So there, I would make a new language, only with the needed commands and nothing more (like c++). No PRINT or PLAY or DRAW or SCREEN. All this would be implemented through libraries. But this would be the syntax I guess. I suppose it comes close to Java? But it's still different in syntax and that it wouldn't need a runtime library to execute.
|
|
Back to top |
|
|
janus Mage
Joined: 29 Jun 2002 Posts: 464 Location: Issaquah, WA
|
Posted: Thu Jul 15, 2004 10:36 am Post subject: |
[quote] |
|
Joakim wrote: | Well I wasn't going to make QB for windows. Not even BASIC for windows. I would make a new language with the same feel and most of the syntax from basic, but make it compleatly OOP and not procedural. I wouldn't be aiming on a basic compatible language (look what it did to c++ to be c compatible), I would aim on somthing like this:
Code: | uses strings, integers, output
class mygame ' default anchestor is Object
function create(args as strings.list) ' default function type is void (required for the creator)
object x, y, i as integers.int32
x = 15
y = 20
for i = 1 to args.count
output.print(args(i))
x.inc
end for
end function
end class
|
I would make it fully OOP like Java, and inherit all objects from a class Object. I would probably include a statement like
final object x as integers.int32 to indicate that x could only be integers.int32 and not anything that inherits that type. Maybe find a better name than 'final'.
Functions would probably be public by default and data would be private by default... There are a lot of things to think about.
So there, I would make a new language, only with the needed commands and nothing more (like c++). No PRINT or PLAY or DRAW or SCREEN. All this would be implemented through libraries. But this would be the syntax I guess. I suppose it comes close to Java? But it's still different in syntax and that it wouldn't need a runtime library to execute. |
Looks like VB.net to me.
|
|
Back to top |
|
|
Joakim Tenshi's Bitch (Peach says "Suck it!")
Joined: 05 Apr 2004 Posts: 64
|
Posted: Thu Jul 15, 2004 10:52 am Post subject: |
[quote] |
|
Really? I wouldn't know... I never tried vb.net. Oh well :) I still kinda want to make it heh.
[edit]
checked it out...
damn it, it is almost identical to vb.net code :/
This happens every time I invent something!
[/edit]
|
|
Back to top |
|
|
tcaudilllg Dragonmaster
Joined: 20 Jun 2002 Posts: 1731 Location: Cedar Bluff, VA
|
Posted: Thu Jul 15, 2004 11:09 pm Post subject: |
[quote] |
|
One of the things I hate about C++ and Java is the level of preparation that must be undertake to do the simplest tasks. Putting all of your resources into independent libraries quickly takes the steam out of any spontaneous decision to code something new. In BASIC everything is standardized. Granted, its slow as hell because BASIC functions were made specifically for reliable use on business machines that didn't need high level graphics and sound quality to get the job done.
What needs to be done then, is to replace QB45. Period. It's a waste, but it's all we have. Everything else seems critically bugged somehow or extravagantly priced by people who are too either greedy or shortsighted maybe(?) to see the incredible impact that a low priced but powerful BASIC could have, or even how popular it could become. So for FIRSTBASIC we have crippleware that can't even run a mouse in its IDE; DARKBASIC, NBASIC, and a host of others we're paying $50.00 for a leisure tool that really doesn't break any boundaries; VB we're getting for free with our college classes when we are impoverished, paying the big bucks otherwise; and a crop of still others so fraught with bugs that no one seriously considers them as reliable development tools.
What we really need is a new QB that writes its PSETs directly to memory; PUTs directly to memory; can do math faster than a chimp; PLAYs to something besides that god awful relic of a speaker. (why again hasn't that been changed to an FM chip by now?); gives REAL control over the keyboard and the mouse; PRINTS either bitmaps OR that ROM stuff; can run a kernal; OUTs more than a byte at a time; Implements a simple pointer scheme without falling into the trap of basing the entire language architecture on them; and finally TYPES that can have TYPES that can have TYPES, and the code actually reflects it. (method functions wouldn't be that bad, either) Simplicity: everything is done for you, everything is done mostly right. That's what we need, nothing else, right?
And please, please do not mention "Well there is this library to do this and this library to do that" because that's the entire problem: people have been running around making fixes for ancient problems for so long that those by now vulnerable issues are still around!
There is so much talent scurrying about this forum. Let's bring an end to it already.
|
|
Back to top |
|
|
janus Mage
Joined: 29 Jun 2002 Posts: 464 Location: Issaquah, WA
|
Posted: Fri Jul 16, 2004 12:45 am Post subject: |
[quote] |
|
LordGalbalan wrote: | What we really need is a new QB that writes its PSETs directly to memory; PUTs directly to memory; can do math faster than a chimp; PLAYs to something besides that god awful relic of a speaker. (why again hasn't that been changed to an FM chip by now?); gives REAL control over the keyboard and the mouse; PRINTS either bitmaps OR that ROM stuff; can run a kernal; OUTs more than a byte at a time; Implements a simple pointer scheme without falling into the trap of basing the entire language architecture on them; and finally TYPES that can have TYPES that can have TYPES, and the code actually reflects it. (method functions wouldn't be that bad, either) Simplicity: everything is done for you, everything is done mostly right. That's what we need, nothing else, right? |
I'm sorry, but that's dumb. Direct memory access? That's not even allowed on modern 32-bit OSes, unless you're running at driver level. We have drivers to write pixels to the screen and manipulate the sound card. We already have TrueType, we don't need another useless bitmap font system. You don't need to run a kernel, your software is already running on one.
And I sincerely hope that this 'new qb' is not going to insist on things like type suffixes and fixed typing.
|
|
Back to top |
|
|
valderman Mage
Joined: 29 Aug 2002 Posts: 334 Location: Gothenburg, Sweden
|
Posted: Fri Jul 16, 2004 1:51 am Post subject: |
[quote] |
|
I kind of fail to see why we would need a new QB at all... _________________ http://www.weeaboo.se
|
|
Back to top |
|
|
tcaudilllg Dragonmaster
Joined: 20 Jun 2002 Posts: 1731 Location: Cedar Bluff, VA
|
Posted: Fri Jul 16, 2004 2:23 am Post subject: |
[quote] |
|
Because complicated systems are so easy to write in BASIC as opposed to C++, because a minumum of preparation is necessary. RPGs will be made that much faster, because it'll be easier to take an idea and run with it. That's why the RPG development community needs a new version of BASIC.
|
|
Back to top |
|
|
valderman Mage
Joined: 29 Aug 2002 Posts: 334 Location: Gothenburg, Sweden
|
Posted: Fri Jul 16, 2004 5:18 am Post subject: |
[quote] |
|
There are numerous game oriented BASIC variants out there already, why create another? _________________ http://www.weeaboo.se
|
|
Back to top |
|
|
tcaudilllg Dragonmaster
Joined: 20 Jun 2002 Posts: 1731 Location: Cedar Bluff, VA
|
Posted: Fri Jul 16, 2004 6:00 am Post subject: |
[quote] |
|
Because they're not free.
|
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|