 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
| Acmlm's Board - I2 Archive - - Posts by Dish |
| Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
| User | Post | ||
Dish Spiny Level: 38 Posts: 381/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
It may seem complex, but it isn't really. If you look at the 8 swapping modes MMC3 does:All my code does is insert the desired default values for all those modes. Swapping on the MMC3 involves 2 writes. First you set the swap mode with a write to $8000, then you write the bank you want to swap to to $8001.
Expanding the ROM is as simple as adding a bunch of extra PRG or CHR banks to the ROM (keep the sizes in powers of 2 -- 8k -> 16k -> 32k -> 64k, etc) and adjusting the header according. However actually USING these new banks does actually take some work -- and yes, it does mean you'll have to add some new code (this is what dan was saying earlier). CHR expansion is easy -- all you have to do is swap in the desired CHR bank and the graphics will change immediately (until another CHR bank is swapped in) PRG expansion takes a bit more work. If you want to access code/data in a new bank you made, you'll have to swap in that bank -- take what you need from that bank, then swap the game's original bank back in. |
|||
|
Dish Spiny Level: 38 Posts: 382/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| I recommend against using a custom black and white palette. Making a palette to compliment the game is one thing -- making a palette manditory for the game is something else entirely. Building a completely custom palette in this method is "cheating" for lack of a better term. Doing an NES palette hack would mean you'd have to use the NES palette. Not a fabricated palette which wouldn't represent the NES in any way whatsoever. Not to mention game specific .pal file association isn't supported by every emu -- which would either make your hack look terrible in those emus -- or forcing the user to change their loaded palette manually every time they want to play your hack (and change back when they're done) -- if they can even change their palette at all. So yeah -- this is a bad idea. Don't do it. If you really want to stick with the whole greyscale idea -- do it right. Use the grey colors in the real palette (all 8 of them). |
|||
|
Dish Spiny Level: 38 Posts: 383/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| I second that. The NES emu I worked on (Schpune) uses like 2-3% of my CPU when displaying in normal, unstretched mode.. but shoots up to like 50-60% when doing 2x stretching. Anyway HH, I'll have to recommend against using StretchBlt at all (or at least, provide an option to do software stretching and BitBlt). StretchBlt is slow as all hell. You can write your own routines to stretch the image by integer scales (2x, 3x) and it'll typically be much faster. |
|||
|
Dish Spiny Level: 38 Posts: 384/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by R2H2 I guess I'm just arguing the principle. Most people (dan, and you apparently) seem to be saying "hey, just do whatever to make it work and to hell with the standards." -- I'm saying "The standards should mean something, and you shouldn't make exceptions for boneheads who don't want to follow them".
That's the thing -- this ISN'T fixing it. This is just feeding it. If these ROMs didn't play in emulators, the problem wouldn't even exist because people wouldn't be spreading around busted ROMs. Like i said before -- if emus were more strict about this kind of thing we wouldn't even be debating this -- since the problem wouldn't exist. So lax header checks are part of the problem. I can't believe it's gotten to the point where an emulator is frowned upon by actually interpretting the file format PROPERLY. I mean seriously -- stand back and look at what you're actually saying, you guys. It's madness. You're saying an emulator should intentionally do things WRONG in order to get a handful of BROKEN games playable. Dress it up with your rationalizations and stats all you like --- but that's what you're saying. I, for one, think that's not only awful, but one of the worst things an emu could do. And no emu should do that. EVER.
Fix it, fine. As long as it prompts me before writing over any of my ROMs. Ignores it, NO. Never. No how. That's absolutly bad. That just feeds the problem. As for making the user find and run obscure programs to fix the problem -- maybe that is a little off the top. I really REALLY wish GoodNES and all the other auditing tools would actually address this problem rather than just completely ignoring it. I mean a simple "[bad header]" in the GoodNES name would work WONDERS towards reducing the number of dumb DiskDude roms around. |
|||
|
Dish Spiny Level: 38 Posts: 385/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Well SMB3 needs IRQs for the status bar to display right. But SMB doesn't use IRQs, so the I flag can stay high the entire time and it won't be a problem. |
|||
|
Dish Spiny Level: 38 Posts: 386/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| which is why it would be 7 3 colors on 2 palettes each = 6, plus the background color = 7 |
|||
|
Dish Spiny Level: 38 Posts: 387/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| My obligatory post to try and persuade you from staying THE HELL away from the wretch that is VB -- and pick up a real language like C/C++. C/C++ aren't as difficult as they're made out to be -- and in fact are easier than VB for many things. It's also far more capable. VB is slow, clunky, and Windows-only, whereas C/C++ can be applied to pretty much anything. It might be simpler to pick up VB and start making Windows programs right away -- but that's really the only edge VB has. Once you get serious you'll have to dive into the API anyway -- and as long as you're doing work in the API, you might as well be doing it in C (it's actually probably easier in C -- and it's certainly faster -- and it won't require an assload of extra files to make your program run). So anyway, yeah. Visual Basic is bad. Stay away. It's expecially bad for beginners because it teaches them backasswards concepts which don't apply to other languages -- so when you move to another language (and you WILL have to -- one day you'll see that VB just doesn't cut it) you'll have to make yourself forget a lot of the garbage VB taught you and re-learn a lot of things from scratch. C/C++ however, have been the base for many, MANY other languages like PHP and Java -- so learning C not only benefits you as a programmer in that its far more powerful/useful than VB, but it also gives you an "in" to all those other languages. |
|||
|
Dish Spiny Level: 38 Posts: 388/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by RYjet911 Just trying to save you time. If you're at all serious about programming, going through VB is an unnecessary and often counter productive step. Many of the things it teaches you will have to be 'unlearned' later when you move to another language. This is doubly true if you're interested in game development. VB just won't cut it. As for your quesitons: 1) Don't bother ;P Avoid VB like the plague. There's not a single person on Earth who's comfortable with C and says "I wish I learned VB" or "I should really learn VB". 2) http://www.gamedev.net/ has many articles addressing this subject. There's even a "for beginners" section linked in the "references" section at the top of the page -- although they focus more on DirectX and Windows specific stuff. If I were you I'd ignore those specific areas and just take the conceptual stuff. For that actual lib to use, I'd recommend SDL (http://www.libsdl.org) for Game development. Using it you can dodge DirectDraw and WinAPI nonsense. Plus it's much, MUCH easier to work with, and is multi-platform. If you want to get into 3D stuff, SDL also works with OpenGL. Neon Helium (http://nehe.gamedev.net) has some very, very good turotials which help you get familiar with OpenGL and 3D rendering. Note OpenGL can also be used for 2D stuff as well. But it's important to know basic programming concepts before you get into drawing, sound, and all the other stuff that goes into game development. The basics probably can be covered by the stuff on cprogramming.com (variables, arrays, pointers, and other fundamentals -- without understanding that stuff you won't be able to make anything). And of course people here will be willing to answer the occasional question. ^^ |
|||
|
Dish Spiny Level: 38 Posts: 389/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| SDL is a cross platform game development library which is built to work with several languages (including C/C++). Basically it's a series of functions you call from your program to do things like get Joypad input, output sound, and do drawing stuffs. It's an alternative to using DirectDraw or some other platform-specific libarary. OpenGL is a cross-platform 3D rendering library. It's the big alternative to Direct3D (which is Windows-only) |
|||
|
Dish Spiny Level: 38 Posts: 390/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| "Unresolved External" errors typically occur when you reference functions that have no body. You have the DialogProc prototype, and you reference the function by passing a pointer to it to DialogBox, but you don't have a DialogProc function body anywhere (or at least it's not finding it) | |||
|
Dish Spiny Level: 38 Posts: 391/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| I stand by my statements. Learning VB (even VB.net) is a wasted/unnecessary/counter-productive step. | |||
|
Dish Spiny Level: 38 Posts: 392/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by marble_eater Not a chance. If it's over 35% I'd be very surpised. But most people certainly do NOT have the .net framework installed. Not everybody updates as soon as updates are available -- in fact most people don't. There are still a lot of people that are still happily running Win98SE without .net. You might be suprised how many. I wouldn't even have the .net framework installed if I didn't install VS.net a while back. I mean I certainly don't use any programs written with it (considering there aren't very many).
I really hate statements like this. I've gone through so many VB vs. C/C++ threads here and I have yet to hear any good examples of exactly how VB is easier (exception listed below). C syntax is about as simple and idiot-proof as it can get. Sure you can write confusing code with it, but generally it's very straightforward. Is it easier to make templated, carbon copy form programs in VB? yes Is it easier to make any other kind of program in VB? definatly not. As soon as you step off of dialogs/forms and move to anything else (in the case of RYjet here, Game Development). VB (even VB.net) will NOT be what you want to go with. Sure it's possible to make games -- but it certainly won't come out as nice, and it will be much harder to program. Care to guess how many commercial programs are written in VB? Zero! The reasons for it are obvious to anyone who's familiar with C/C++ -- they're just superior languages. VB was designed to make Windows form programs easier to make, whereas C/C++ weren't designed for any specific purpose. They were designed to be applied to anything. Game Development is just 1 example, it's hardly the only example. Like I said pretty much anything beyond the templated pushbutton, editfield forms will be easier to do in another language. That's really where VB's practicality stops (if it ever existed in the first place). As for the advantages of .net -- I'm personally not a fan, but all of them apply to C/C++ as well (.net is not VB specific, C/C++ can use it too). So discussion of how awesome .net is doesn't really have anything to do with choosing VB over C/C++. It has to do with using .net over SDL or the API or whatever other library you want to go with.
On a 3.2GHz machine -- sure. On us old fogeys who have had their comps for a while (most people), not on your life. Efficient C/C++ is blazing fast. On slower computers, the difference IS noticable when writing programs that take a decent amount of CPU power. On programs that don't it'll be instantaneous with either language - but that goes without saying. Considering RYjet wants to get into Game Development -- speed WILL be an issue. Games are the most CPU intensive programs around.
Object Orientation is a programming concept/style, not a language feature. Pretty much any language (hell, even 6502) can be object oriented if you code a certain way. Forced object orientation (like what Java does) is something I'll never understand. It's so impractical. Not everything calls for OOP and some things are better without it.
Sure -- slapping together pre-existing code to create a cookie cutter program is much faster to do in VB (that's pretty much what it was designed for). But when you actually want to build an independent program, C/C++ will get the job done just as fast or faster.
Haw. Like I said before --- people who are comfortable with C/C++ never go back to VB for anything other than the quick cookie-cutter app. There's just no reason to. C/C++ is not as difficult as it's made out to be, and it's certainly far more flexible than you're making VB out to be. Not to mention it has crossplatform libs up the wahzoo (FMod, SDL, wxWidgets, GDK+ just to name a few), making C/C++ programs able to run on FAR more plaforms than VB ever could. Speed, simplicitiy, ease of use, portability, outside support (in the form of libs, sample code, tutorials, etc). C/C++ just dominate the field. Most people that start with VB eventually have to leave it -- it just doesn't do the job. Going through it is just an unessecary step. Start with C/C++ rather than wasting time with VB before switching over. |
|||
|
Dish Spiny Level: 38 Posts: 393/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by marble_eater The average computer user is not tech savvy. They buy a computer and they use whatever is on it. Until recently, .net did not come build pre installed into computers. Most people do not have a brand new computers -- most people aren't running Windows XP -- most people do not have .net installed. In certain circles, like say someone in the programming industry or someone with a corporate office job involving computers. Yeah -- they and probably everyone they know will have the .net framework installed. But that hardly is an example of the general population.
I said "as simple and idiot proof as it gets". Of course that doesn't mean 100% idiot proof. Beginners in any language will be plagued by compile errors at first. It's part of the learning process. Once the concepts are grasped the rest of the language falls into place -- and the way in which C operates just 'clicks'. The beauty of C is that it's very low level (for a high level language anyway), so the concepts it teaches are easily applied to any and all programming languages. This is especially true considering the myriad of language that are based on C (C++, Java, C#, PHP, etc). VB focuses more on abstracted concepts (since it's a level or two higher than C) which aren't as applicable to other languages. This is what I was referring to before when I said a lot of stuff learned from VB must be "unlearned" when you move from it.
That's not to say it can't be done. I'm saying it could be done as easy or easier in another language. And it could. VB was designed for a specific purpose -- C was not designed for anything specific, thus it's more easily adaptable.
I would love some examples (note I said games, not programs -- I'm sure there are more VB programs around). Could you link me to an info page or just give me the names of them so I can research them?
Since I'm not a professional programmer -- I couldn't say. I don't doubt you here though.
When a language can do anything another language can and much more, "superior" seems like the proper word to use to me.
But see... this is a .net argument, not a VB argument. You're saying "VB can do it", which I know it can. I'm saying "C does it better", which it does.
Then you're doing yourself a disservice. Seriously -- other languages can use the .Net framework and are much more powerful. Look into them. VB is the bottom of the barrel. I know VB CAN make these programs -- I'm saying other languages make them more easily and better.
Like I said while I'm not a fan of the .Net framework, I'm not debating it here. I'm saying VB should be avoided. That says nothing about .Net. Many many langauges, including C++, can use the .Net framework just as well as VB can.
That underlined portion basically sums it up -- VB is slower than other languages. You're impressed by the speed of JIT compiled VB, but really it probably just made VB's speed tolerable.
Granted, I don't have very much VB experience at all. But there's really no reason for me to get into it, C/C++ is superior (I know you don't like me saying that, but I don't know how else to describe it). Most VB code I've seen can be converted line-by-line to C/C++. There's nothing VB offers that can't be easily accomplished in C/C++ (aside from those cookie cutter apps). On the reverse there is loads upon loads that C/C++ can do that VB can't touch. PLUS C is faster.
Like I said before, OOP is a programming style/concept. Not a language feature. Pretty much any language can make OOP code.
So VB is less crappy than it was before. There's still lots to C/C++ that isn't in VB -- which is my point.
If you don't want to deal with memory management, use libs to manage it. C++ has plenty. If you don't want to use pointers, don't use them. Not having the OPTION to manage memory or use pointers is nothing but a hinderance, and another reason why VB isn't as good. You basically just listed two reasons NOT to use VB.
On the contrary, once you grasp the concept of pointers and understand how powerful they are to use... it's an incredible hinderance to no longer have access to them. C++ programmers don't love their pointers because it's the cool thing to do -- they love them because they're an incredible tool -- and any langauge lacking them severly suffers because of it. This is a rather abstract example -- but try making an NES emu without using pointers (pointers for like PRG/CHR banks and nametable mirroring modes). It will be a massive pain in the ass and will require a massive amount of unnecessary memory copying. Now I know this isn't exactly directly applicable to your average program -- but the kinds of concepts that are acquired after doing something like this REALLY shows how valuable pointers are. Afterwards you can find ways to use them all over -- and not just because you can, because it makes things easier/more efficient.
I was talking about C/C++ Simplicity in that the syntax is consistent, straightforward, easy to learn, and very logical. The thing about C is it's incredibly basic. The data types it provides are simple chars, shorts, longs, floats -- just raw memory storage. Even pointers are nothing more than integer variables in a different context. Everything in the language revolves around that very simple foundation. In fact it's SO simple, it provides everything you need. There's no limit to the number of complex data types you can build off of those most simplistic data types -- but they're not part of the C language. C keeps things simple. It keeps it minimal. Ease of Use, while interpretive, really depends on your understanding of programming fundamentals. If you grasp the most basic concepts of variables, arrays, pointers, etc, then it is very easy to apply these concepts in C. There are no abstract concepts above these (at least not in C, there may be in whatever libraries you're using). Portability:
Name one platform VB can run on that C can't. I'll save you some time: there aren't any. On the reverse there are plenty that C can run on that VB can't. C is more portable. Of course the portability of individual programs depends on which libraries you use. However the available C/C++ libraries can be used to build a program for any modern PC, and even some consoles.
As previously addressed -- that brings VB up to a tolerable speed. It still doesn't bring it up to par with C/C++ in this department.
That says nothing about the language -- which can target multiplatform. I could just as easily say most VB programmers target windows exclusively. The point is C/C++ can do it.
You and your friends have my condolences. The curse of VB has held you back.
If you can give me ONE example of a program that would be stupid to take up in C++, I'd love to hear it. Keep in mind you can use the .Net framework with C++. C++ gives you more control, it's faster, it's got a wide range of libraries available... it really is built to take on any task. There's nothing VB offers that can't be just as easily accomplished in C/C++, and there is SO much C/C++ offers that VB can't touch.
That's ridiculous. The C++ programmers that look down on VB do so more because it's slow, bloated, far more restrictive, and offers far less control over your program. Like I said, once you get comfortable with C/C++, there's absolutely no reason to use VB anymore (outside the cookie cutter apps VB does so well).
I'd love to see an example.
How fast is your computer? What kind of programs do you write? What's "fast enough" for you, might be painfully slow for someone else.
Haw. Yes that's why exactly. =P |
|||
|
Dish Spiny Level: 38 Posts: 394/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Sorry I scared you off. I really wish you had read my last post because I think it got a lot of my points across quite well. "How about you give the original poster the facts (i.e. pros and cons to using C++ over VB, NOT YOUR OPINION AS TO WHICH LANGUAGE IS BETTER)" If it were a matter of opinion, I could understand your gripe. The bottom line is C++ is more powerful, more flexable, and not as difficult to learn as it's made out to be. Those are the pros. I have yet to hears cons other than "VB can do some things easier" -- of which several times I've requested examples and have not received. I've addressed the reasons why C++ would benefit him, specifically targetting game development, which he mentioned he has interest in. I'm not trying to shove C++ down his throat, I'm just trying to save him some time, because I'm sure that (for what he wants to do -- game development), VB will end up being more of a hinderance to him. Unfortunately, he can't really weigh them for himself until he's tried them. He'll have to dive somewhat blindly into one or the other -- I'm trying to guide him to the one that will make his future programming projects go more smoothly. I'm sorry you took my posts to be so personal and hostile. I get the feeling you were misunderstanding what I was saying a lot of the times (as I tried to point out in the previous post). I'm also sorry you made me out to have some sort of C++ fetish. I'm sorry you assumed I had a leetist attitude because I don't use VB. I'm sorry you think many C++ coders dislike VB just because of nonsensical leetist reasons -- and I'm sorry that you don't accept that there are real, legit reasons to dislike VB. I'm sorry you had to run away from the debate in a fit of frustration. Perhaps I'm not the one that needs to take his head out of his ass. [edited for typos] (edited by Disch on 05-06-05 02:16 PM) |
|||
|
Dish Spiny Level: 38 Posts: 395/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Offset $00004 = Number of 16k PRG banks. (keep a power of 2 value!) Offset $00005 = Number of 8k CHR banks (0 implies 8k of CHR RAM -- no CHR ROM in the .nes file) (keep a power of 2 value!) High 4 bits of Offset $00006 = Low 4 bits of mapper number High 4 bits of Offset $00007 = High 4 bits of mapper number The Low 4 bits of Offset $00006 specifies hardwired mirroring mode (if mirroring is hardwired), and has the SRAM flag (whether or not the ROM uses a .sav file): Bit 3: If on, game uses 4-screen mirroring Bit 2: If on, 512-byte trainer exists before PRG data (don't bother with this) Bit 1: If on, game uses a .sav file to save SRAM Bit 0: 0 = Horizontal Mirroring. 1 = Vertical Mirroring (assuming bit 3 is off) Note 4 screen mirroring should only be used on mappers which support it (only one I know of is MMC3) Following that 16 byte header is the 512 byte trainer (if it exists -- it usually doesn't). After that is all the PRG pages, followed by all the CHR pages. Typically mappers need a nice even power-of-2 value for PRG/CHR sizes, so if you expand PRG/CHR, the minimum you can add is doubling what's there. So in SMB, to expand you'd have to bump it up to 64k PRG. Be sure not to go over the maximum the mapper allows (this won't be a problem for you though -- MMC3 can hold plenty more than 64k PRG and however many CHR pages you want to add [within reason]) Where to add the extra PRG depends on the mapper. MMC3 has the last 8k "hardwired" to $E000-$FFFF -- you'll probably want to keep this here (this is where the Reset/NMI/IRQ vectors are -- they need to be at $FFFA), so if you add PRG, you want to add it before that bank. Typically your best best is to squeeze in your extra PRG right before the last 16k of PRG. So if you double SMB's PRG, squeeze in the extra 32k at offset $04010 (edited by Disch on 05-06-05 07:12 PM) |
|||
|
Dish Spiny Level: 38 Posts: 396/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Are you still using 0 for the dialog ID? That's the only thing I can see that's flakey. Double check to make sure the dialog uses the proper ID in whatever resource editor you're using, and make sure 'frmMain' shares the same integer as the dialog. If you can, try changing it to something other than zero (perhaps zero has some special significance or something?) Only other thing I can think of is maybe you have to create a parent window for the dialog -- but you shouldn't have to for Modal dialogs. I'll put my money on the resource ID though. |
|||
|
Dish Spiny Level: 38 Posts: 397/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by R2H2 Ah, you're right. I missed that part when I looked it up. So it's not the parent window. It's not the Dialog Proc It's not the HINSTANCE (at least not in the code you pasted before) Only thing left is the resource ID -- only thing I can think of is the resource editor you're using doesn't make the dialog to have the same ID as what's defined in your header file.
Not to my knowledge -- I don't know what those codes mean (I tried looking them up, didn't find anything). WM_LBUTTONDOWN and WM_LBUTTONUP are used for mouse clicks -- they don't go through WM_COMMAND afaik (could be wrong though... WM_COMMAND is pretty strange).
Dialog Boxes don't get WM_CREATE messages (and least not if you use DialogBox). Instead you get a WM_INITDIALOG. Actually, Dialogs are half-assed windows -- not all messages get through to your message handler. |
|||
|
Dish Spiny Level: 38 Posts: 398/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Is your WM_CLOSE section being called right away for some reason? Try taking that part out, and instead have WM_COMMAND with BN_CLICKED for IDCANCEL and IDOK your close markers (which I think is what you're supposed to do anyway). | |||
|
Dish Spiny Level: 38 Posts: 399/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| My $0.02: Avoid scrolling layouts. Browsers already come equipped with vertical scrollbars -- making the user have to flip between using that scrollbar and using your personal scrollbar is a pain (I usually just don't even bother to read the cut off portion of people's posts when they make me scroll). A good layout will stretch and work around the post, regardless of the post's size. The layout should fit the post -- not the other way around. |
|||
|
Dish Spiny Level: 38 Posts: 400/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Looks like the right forum to me |
| Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
| Acmlm's Board - I2 Archive - - Posts by Dish |
