Your naming convention using all caps like that makes the code hard to read. Have you run it through a debugger such as GDB? One thing that stands out is that you do no bounds checking when indexing...
Type: Posts; User: Syscal
Your naming convention using all caps like that makes the code hard to read. Have you run it through a debugger such as GDB? One thing that stands out is that you do no bounds checking when indexing...
So, I have a bare bones MOS 6502 emulator written in C. It has all of the OPCodes implemented. What is the next step? It follows the basic fetch decode execute cycles. Do I need an...
If you malloc the memory after declaring your pointer it would work since that would be stored on the heap.
Yeah, but code clarity is more important in my opinion (If it's to be shared with others anyways).
Very cool! I'm glad to see folks to an interest into this thread!
I beg to differ on #1. It gets freed at the end of main. I appreciate the feedback!
This was all for fun, and I enjoyed researching bitmaps. It's not complete by any means but a 24 bit bmp file is advised for now. You'll need to name the file accordingly and modify the macro...
In the second post, yes, I opted to replace the whole blue sample in pixels. It's not consecutive pixels it would be every 3rd (or whatever I choose). So far it's undetectable to me and thats with a...
I guess this is no longer needed... I thought of another way of doing it thats still undetectable to the human eye and still only modifies the blue samples of each 3rd pixel:
do
{
...
What I am intending to do is encode data into the 4 least significant bits of each blue sample of every pixel regardless of bits per pixel in a BMP file. Lets assume 24 bits per pixel however. I am...
Yup, I figured as much which is why I went back and edited the post. Too slow and you beat me to the punch though. Had to really sit there and think about that before I realized what was happening....
#include <stdio.h>
int main(int argc, char ** argv) {
printf("hello!!!"+printf("world"));
return 0;
}
Ah hah! It makes sense to me now. Great read!
So here's another question... Why aren't the other fields padded as well? sizeof(BitMapFileHeader) returns 16 (2 additional bytes from the padding of sig).
Additionally, fread on the header is...
Whats the legal recourse for something like this?
#pragma pack(1) did the trick... I appreciate the help guys. Interesting I never heard of structs being padded like this. Time to do some further research.
I've been looking into the file structure of BMP images and everything I'm reading says that the 4 bytes following the signature are designated as the filesize of the bmp file... It's always zero for...
The specific ones I want are the ARP OpCodes and the Hardware Identifiers (I guess I could use ETHERTYPE_* instead for those since they share a common number space)
When you say kernel side...
Hm... That took care of it O_O But see there is some stuff (Constants really) that I need that are defined in that header. Do you see any issue with taking and defining them in my header file?
Not sure what's going on here but I have several linux header files included and when I compile my program I get the below errors... I'm not sure how I should go about fixing it? Am I NOT supposed to...
I have written a simple inet_ntop function which appears to work for the majority of the calls but there are some where I believe it's returning an incorrect IP address...
I have accounted for...
I was looking through the winpcap documentation and noticed this bit of code...
/* From tcptraceroute, convert a numeric IP address to a string */
#define IPTOSBUFFERS 12
char...
I never could get SDL2.0 to work... Kept getting an "undefined reference to winmain@16" error when the linkage was all correct. Went back to SDL 1.2 and everything works fine. :P
It's amazingly confusing yet it works... Somehow he operates on string literals to execute opcodes... I have a function for every single opcode in my MOS 6502 emulator and I think anyone could follow...
Can't say that it's deliberate since he posted the video and code for "educational purposes". The code is part of an NES emulator he has written. I for one can't follow the code when the most of it...